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FOREWORD 

This  material  is  published  as  part  of  Contract  N00014- 
76-C-0732  with  the  Office  of  Naval  Research,  United  States 
Department  of  the  Navy,  entitled,  The  International  Purdue 
Workshop  on  Industrial  Computer  Systems  and  Its  Work  In 
Promoting  Computer  Control  Guidelines  and  Standards . This 
contract  provides  for  an  indexing  and  editing  of  the  results 
of  the  Workshop  Meetings,  particularly  the  Minutes,  to  make 
their  contents  more  readily  available  to  potential  users.  We 
are  grateful  to  the  United  States  Navy  for  their  great  help 
to  this  Workshop  in  this  regard. 


Theodore  J.  Williams 
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BACKGROUND  INFORMATION  ON  THE  WORKSHOP 

The  International  Purdue  Workshop  on  Industrial  Computer 
Systems,  in  its  present  format,  came  about  as  the  results  of  a 
merger  in  1973  of  the  Instrument  Society  of  America  (ISA)  Com- 
puter Control  W'orkshop  with  the  former  Purdue  Workshop  on  the 
Standardization  of  Industrial  Computer  Languages,  also  cospon- 
sored by  the  ISA.  This  merger  brought  together  the  former- 
workshops 1 separate  emphases  on  hardware  and  software  into  a 
stronger  emphasis  on  engineering  methods  for  computer  projects 
Applications  interest  remains  in  the  use  of  digital  computers 
to  aid  in  the  operation  of  industrial  processes  of  all  types. 

The  ISA  Computer  Control  Workshop  had  itself  been  a re- 
naming in  1967  of  the  former  Users  Workshop  on  Direct  Digital 
Computer  Control,  established  in  1963  under  Instrument  Society 
of  America  sponsorship.  This  Workshop  in  its  annual  meetings 
had  been  responsible  for  much  of  the  early  coordination  work 
in  the  field  of  direct  digital  control  and  its  application  to 
industrial  process  control.  The  Purdue  Workshop  on  Standardi- 
zation of  Industrial  Computer  Languages  had  been  established 
in  1969  on  a semiannual  meeting  basis  to  satisfy  a widespread 
desire  and  need  expressed  at  that  time  for  development  of 
standards  for  languages  in  the  industrial  computer  control 
area . 

The  new  combined  international  workshop  provides  a forum 
for  the  exchange  of  experiences  and  for  the  development  of 
guidelines  and  proposed  standards  throughout  the  world. 
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Regional  meetir  - are  held  each  spring  in  Europe,  North 
America  and  Japan,  with  a combined  international  meeting  each 
fall  at  Purdue  University.  The  regional  groups  are  divided 
into  several  technical  committees  to  assemble  implementation 
guidelines  and  standards  proposals  on  specialized  hardware 
and  software  topics  of  common  interest.  Attendees  represent 
many  industries,  both  users  and  vendors  of  industrial  compu- 
ter systems  and  components,  universities  and  research  insti- 
tutions, with  a wide  range  of  experience  in  the  industrial 
application  of  digital  systems.  Each  workshop  meeting  fea- 
tures tutorial  presentations  on  systems  engineering  topics  by 
recognized  leaders  in  the  field.  Results  of  the  workshop  are 
published  in  the  Minutes  of  each  meeting,  in  technical  papers 
and  trade  magazine  articles  by  workshop  participants,  or  as 
more  formal  books  and  proposed  standards.  Formal  standardi- 
zation is  accomplished  through  recognized  standards- issuing 
organizations  such  as  the  ISA,  trade  associations,  and 
national  standards  bodies. 

The  International  Purdue  Workshop  on  Industrial  Computer 
Systems  is  jointly  sponsored  by  the  Automatic  Control  Systems 
Division,  the  Chemical  and  Petroleum  Industries  Division,  and 
the  Data  Handling  and  Computations  Division  of  the  Instrument 
Society  of  America,  and  by  the  International  Federation  for 
Information  Processing  as  Working  Croup  5.4  of  Technical 
Committee  TC-5. 
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The  Workshop  is  affiliated  with  the  Institute  of 
Electrical  and  Electronic  Engineering  through  the  Data 
Acquisition  and  Control  Committee  of  the  Computer  Society 
and  the  Industrial  Control  Committee  of  the  Industrial 
Applications  Society,  as  well  as  the  International  Federation 
of  Automatic  Control  through  its  Computer  Committee. 
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INTRODUCTION 


The  Office  of  Naval  Research  of  the  Department  of  the 
Navy  has  made  possible  an  extensive  report,  summary  and  index- 
ing of  the  work  of  the  International  Purdue  Workshop  on 
Industrial  Computer  Systems  as  carried  out  over  the  past 
eight  years.  This  work  has  involved  twenty-five  separate 
workshop  meetings  plus  a very  large  number  (over  100)  of 
separate  meetings  of  the  committees  of  the  workshop  and  of 
its  regional  branches.  This  work  has  produced  a mass  of 
documentation  which  has  been  severally  edited  for  the  original 
minutes  themselves  and  then  again  for  these  summary  collec- 
tions . 

A listing  of  all  of  the  documentations  developed  as  a 
result  of  the  U.S.  Navy  sponsored  project  is  given  in  Table  I 
at  the  end  of  this  introduction.  The  workshop  participants 
are  hopeful  that  it  will  be  helpful  to  others  as  well  as 
themselves  in  the  very  important  work  of  developing  guidelines 
and  standards  for  the  field  of  industrial  computer  systems  in 
their  many  applications. 

A major  part  of  the  efforts  of  the  Workshop  at  its 
several  meetings  has  been  a continuing  review  of  the  state-of 
the- art  and  the  needs  of  the  computer  field  in  general  and 
of  the  industrial  computer  applications  field  in  particular. 

This  has  been  accomplished  through  a set  of  tutorial  presenta- 
tions made  to  the  workshop  attendees  by  recognised  experts  in 
the  field  and  through  specific  studies  undertaken  by  the  several 
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committees  of  the  Workshop.  The  tutorials  presented  to  date 
are  listed  in  Table  II.  None  are  reproduced  here  because  of 
the  volume  involved.  Those  interested  are  referred  to  the 
original  Minutes  as  noted.  This  Part  of  the  Summary  of  the 
results  of  the  Workshop  is  devoted  to  reports  of  the  second 
kind,  i.e.,  those  developed  by  the  several  committees  of  the 
Workshop  is  part  of  their  regular  studies.  A large  part  of 
the  specific  reports  generated  by  the  committees  were  those 
concerning  the  functional  requirements  for  the  several  indus- 
trial computer  application  areas.  Several  of  these  are 


included  in  this  Part. 
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TABLE  I 


A LIST  OF  ALL  DOCUMENTS  PRODUCED  IN  THIS 
SUMMARY  OF  THE  WORK  OF  THE 
INTERNATIONAL  PURDUE  WORKSHOP  ON  INDUSTRIAL 
COMPUTER  SYSTEMS 


The  International  Purdue  Workshop  on  Industrial  Computer 
Systems  and  Its  Work  in  Promoting  Computer  Control 
Guidelines  and  Standards , Report  Number  77,  Purdue 
Laboratory  for  Applied  Industrial  Control^  Purdue 
University,  West  Lafayette,  Indiana,  Originally  Published 
May  1976,  Revised  November  1976. 


An  Index  to  the  Minutes  of  the  International  Purdue 
Workshop  on  Industrial  Computer  Systems  and  Its 
Predecessor  Workshops , Report  Number  58,  Purdue  Laboratory 
for  Applied  Industrial  Control,  Purdue  University, 

West  Lafayette,  Indiana,  January  1977. 


A Langua.-.  e Comparison  Developed  by  The  Long  Term 
Procedural  Languages  Committee  - Europe , Committee  TC- 3 
of  Purdue  Europe , Originally  Published  January  1976, 
Republished  October  1976. 


Significant  Accomplishments  and  Documentation  of  the 
International  Purdue  Workshop  on  Industrial  Computer 
Systems . 


Part  _L  - Extended  FORTRAN  for  Industrial 
Real-T  ime  Applications  and  Studies  in 
P roblem  Oriented  Languages . 


Part  II  - The  Long  Term  Procedural  Languages 


PART  III  - Developments  in  Interfaces  and 
Data  Transmission , in  Man -Machine  Communica- 
anH 


tions  and  in  the Sale tv  

Industrial  Computer  Sys terns . 


and  Secur i. 


ty  oi 


Part  IV  - Some  Reports  on  the  State-of- the- 
Ar t and  Functional  Requirements  for  Future 

Applications • 


Part  V - Documents  on  Existing  and  Presently 
Proposed  Languages  Related  to  the  Studies  of 
tine  Workshop  . 


TABLE  I (Cont.) 


PART  VI  - Guidelines  for  the  Design  of  Man /Ha chine 
Interfaces  for  Process  Control 


All  dated  January  1977 

The  latter  seven  documents  are  also  published  by  the 
Purdue  Laboratory  for  Applied  Industrial  Control,  Purdue 
University,  West  Lafayette,  Indiana. 
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TABLE  II 

LIST  OF  TUTORIALS  PRESENTED  AT 
PURDUE  WORKSHOP  MEETINGS 

I .  International  Meeting  - F a 1 1 1973 

1.  Mr.  Alonzo  R.  Parsons,  Honevwell,  Inc. 

"National  and  International  Standards 
Organizations  and  Their  Relation  to 
the  Work  of  the  Purdue  Workshop" 
November  26,  1973 

2.  Mr.  Donald  C.  Loughry,  Hewlett-Packard  Co. 

"Byte  Serial  - Bit  Parallel  Datawav 
Standards  Proposals  of  Working  Group 
3 - IEC  TC  - 65" 

November  27,  1973 


Both  tutorials  were  published  in  the  Minutes,  First 
International  Meeting,  November  1973. 


1 1 . American  Regional  Meeting  - Spring  1. 9 7 A 

3.  Professor  Peter  Denning,  Purdue  University 

"On  the  Significance  of  Virtual  Storage" 

April  1,  1974 

4.  Mr.  David  Frost,  Honeywell,  Inc. 

"An  Overview  of  Structured  Programming" 

April  1,  1974 

5.  Mr.  Frank  Engel,  Jr.,  ANSI  X3J3 

"The  Work  of  the  ANSI  FORTRAN  Committee 
X3J3  and  Its  Relation  to  the  Purdue 
Workshops" 

Ap  r i 1 2 , 1974 

All  of  the  above  tutorials  were  published  in  Minutes  of 
Spring  Meetings  1974. 
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TABLE  II  (Cont.) 


III.  International  Meeting  - Fall  1974 


6.  Mr.  Bobby  L.  Hartwav,  Los  Alamos 
Scientific  Laboratory 

"A  Tutorial  on  Human  Factors" 
October  8,  1974 


7.  Mr.  Robert  Van  Naarden,  Digital  Equipment 
Corporation 

"A  Tutorial  on  Micro-Computers" 
October  8,  1974 


Tutorials  listed  above  were  published  in  the  Minutes, 
Second  Annual  Meeting,  October  1974. 


IV.  American  Regional  Meeting  - Spring  1975 


8.  Mr.  Bobby  L.  Hartway,  Los  Alamos 
Scientific  Laboratory 

"Human  Factors  in  Engineering" 
April  15,  1975 


9.  Mr.  William  B.  Field,  Union  Carbide  Corporation 

Mr.  F.  Mark  Rehnvorg,  ACCO-Bristol  Division 

"Implementation  of  a Problem  Oriented 
Language  Using  a Microprocessor" 

April  15,  1975 

Tutorials  listed  above  were  both  published  in  the 
Minutes,  Spring  1975. 

Far  East  Regional  Meeting  - Spring  1975 


10.  Mr.  S.  Gocho,  Nippon  Mining  Company 

"On  the  Industrial  Computer  Networks" 
July  2,  1975 


This  tutorial  was  not  available  for  publication. 
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TABLE  II  (Cont.) 

V.  International  Meeting  - Fall  1975 


11.  Mr.  William  B.  Field,  Union  Carbide  Corporation 

"A  Tutorial  on  Distributed  Control 
via  Dynamic  Simulation" 

October  28,  1975 

12.  Mr.  William  B.  Field,  Union  Carbide  Corporation 

"A  Tutorial  on  Systems  Reliability 
and  Safety" 

October  30,  1975 

Copies  of  above  listed  tutorials  were  not  available. 


American  Regional  Meetim 


1976 


13.  Mr.  Fred  G.  Sheane,  Chairperson,  Imperial 
Oil  Enterprises,  Ltd. 

Mr.  John  Lee,  Foxboro  Company 

Mr.  C.  R.  Stewart,  Honeywell,  Inc. 

Mr.  Vincent  J.  McKnight,  Taylor  Instrument  Companies 

Mr.  Bruce  Allen,  ACCO  Corp . 

"Impact  of  Microprocessor  Based 
Digital  Instrumentation" 

April  6,  1976 

14.  Ms.  Mary  Adix,  General  Motors  Corporation 

"ILIAD:  A High-Level  Language  for 

Industrial  Control  Applications" 

April  7,  1976 

15.  Mr.  Warren  E.  Loper,  Naval  Electronics 
Development  Center 

"The  TINMAN  Requirements  for  the  DOD 
Higher  Level  Common  Language" 

April  6,  1976 
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TABLE  II  (Cont.) 


16.  Dr.  James  S.  Miller,  Intermetrics,  Inc. 

"The  CS-4  Language" 

April  7,  1976 


Copies  of  these  discussions  were  published  in  the 
Minutes  of  the  American  Regional  Meeting,  April  1976. 
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SECTION  I 


FUNCTIONAL  REQUIREMENTS  FOR  INDUSTRIAL 
COMPUTER  SYSTEMS 


One  of  the  early  committees  of  the  Purdue  Workshop  on 
Standardization  of  Industrial  Computer  Languages  was  one 
called  the  Functional  Requirements  Committee.  Its  job  was 
to  develop  those  functional  requirements  of  an  industrial 
computer  system  which  would  serve  as  a basis  for  the  efforts 
of  the  Workshop  in  its  developing  of  standard  industrial 
computer  languages.  This  committee  finished  its  work  at  the 
time  of  the  Fifth  Meeting  of  the  Workshop  and  was  then 
discharged.  The  attached  report  is  the  findings  of  the 
committee  which  were  published  on  pp.  53-99  of  the  Minutes 
of  the  Fifth  Workshop. 
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FUNCTIONAL  REQUIREMENTS  FOR  INDUSTRIAL 
COMPUTER  SYSTEMS 


(Adopted  by  the  Workshop  on  Standardization 
of  Industrial  Computer  Languages  - May  6,  1971) 


FUNCTIONAL  REQUIREMENTS  COMMITTEE  OBJECTIVE 


The  main  objective  of  this  committee  has  been  to  develop 
functional  requirements  for  industrial  computer  systems  tc  :/j’v 
as  a basis  for  the  development  of  standard  industrial  ccmprut'-r 
programming  languages.  These  functional  requirements  nould 
be  sufficiently  broad  to  encompass  most  application'  ;f  indust- 
rial computer  ’.ys terns,  but  it  is  not  required  that  all  func- 
tional requirements  apply  to  all  application  areas  or  ary 
specific  installation.  If  a function  _is  tc  be  implemented, 
it  should  satisfy  the  applicable  functional  requirement", 
as  defined  herein. 

The  intent  is  that  the  following  functions  will  be  pro- 
vided by  some  means  in  the  languages  and/or  stand-  rds  bo in  ; 
developed  by  the  various  subcommittees  of  this  Workshop. 

Various  examples  given  are  for  illustrative  purposes  cr.lyj 
it  is  not  intended  that  the  range  of  application  of  there 
standardized  functions  be  particularly  limited  to  the 
range  of  the  example  used. 


„ HttCSDItO  .PAflS  BUkNtUHOT  flLM&D 
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SUMMARY  OF  RECOMMKNDEI  FUICTT-  :AL 
REQUIREMENTS  FOR  INDUSTRIAI  COMPUTE!-;  SYSTEMS 

Tlfl’KODUCTION 

Although  Industrial  computers  • >•  • used  " ••  a wid  /ari<  ty 
i f apj licati ons , c< rt ain  simi  pities  i . i t uch  a way 

that  s tandardi  :atioi  can  offer  u • h ml  l > nef it , 

reduced  pr<  jramming  if  fort,  for  r:  and  ippliers  hese 
systems . 

An  industrial  computer  system  is  one  that  :ommunica1 
:■  at  ufactu ring  process  it  whal  ::  ■ 1 a nrea3  tin 

ting  information  from  the  proctor  at  a rate  high  enou 
be  of  use  in  some  form  of  contrc  1 of  the  j r<  jess  il 
1 lis  includ  c a wd  de  dyt  ■ :■  : ■ rat  ■ f pj  icati  ns , froi 
serve  syste  as  with  fr<  luency  respot  ;es  many  ;ycl<  3 
second,  ini  the  management  inf  rmation  and  :ontr  3 

dea3 ing  with  business  cycles  of  se\  r ; y ars  per  • . ■ 1 . 

rh  ■ common  feature,  communicate  n with  th  ] r cess, 
worthy  of  standardisation. 

All  processes  are  managed  by  po.  pie , so  a 1 oomputi  r -y  • 
have  some  moans  for  man/ma chine  communication.  , ••in’,  v . 
means  are  worthy  of  standards  ation  t<  sot  :tent, 
though  the  hardvr  re  used  and  tin-  man  in  the  lor  in  1 • rt- 
'••ular  It, rations  may  vary  -.onsidorably. 

V irious  coiiusoii  functions  :ir<  n»  ! a 1 .1  osually  suited  i > 

; . , ; • at  j n.  ; 3 1 1 ■ t!  i ar  or  ;ull 
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standardisation  arc  a l.-  more  suit- -o  !•>  u.  i ' x.r.  "L 

< ri 1 >i(.- >dn  ! an; juages,  and  at  l ndled  . ' ; i ■ t dul 

or  packa* ;es . ther , Less  disciplined  funct j n n ..  r iuire 
g< >nerati on  of  application-  riented  prograrami  ig  packa 
using  "pr  ledur;  l"  V ngu  tges,  tut  the  \ r ••••  dur  1 Langu 
: ay  bo  worthy  of  standardl  ’.at ion  even  though  the  pac 
generated  bear  nc  similarity  whatsoever.  Thus,  si  .no  rd- 
i at ion  is  directed  toward  that  effort  where  It  can  provide 
a benefit,  not  a penalty. 

rh  - rgani  atler  of  functional  requirements  tl  at  fc 
has  n<  si  jni  :ance.  It  was  used  by  the  Function:  i : ilr  - 
: ent  ■ Committee  of  the  Workshop  as  a way  t<  < rgani  its 
wc  rk , numerous  cross-references  wi  1 : >"  ..  xnd  in  tb  •••  - 

suit,  ri  whole  task  could  Just  as  well  have  beer  divid  I 
int<  "System  reneration"  and  "Systen  Maintenance",  r 
example.  Current  state-of-the-art  limitations  have  bee 
ignored,  and  the  functional  requirements  should  be  inter- 
preted with  this  in  mind,  (For  example,  c 1 sider  t ie 
. • ni  ' digit;  1 transducers.  Function;  lly,  they 
.'.a me  the  familiar  analog  inputs,  so  no  distinct!  a 
made  her  . Even  logical,  event-oriented  inputs  t y t- 
considered  to  be  one-bit  annlog-tc -digital  eonver  In 
if  a process,  measurement.) 

e 1 ••  rdw;  r ifiguration  limitations  have  been  con  L. 

It  may  s !1  be  the  case  that  a standardj  s.ed  scheme  f»  ••  y-  : 


ccnrr  tt  n n ;ul more  hardware,  temporarily,  than  ••  c 
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be  justified  for  the  industrial  application.  Rather  than 
exclude  small  systems  from  the  benefits  of  standard! . tin. 
in  system  generation,  or  require  all  systems  to  be  1 rger 
than  the  run-time  application  requires,  the  standards  d, 
not  require  system  generation  to  be  done  on  the  object 
machine,  nor  do  they  prevent  it  fixe  being  done  on  tire  re- 
ject machine.  In  fact,  tiim  -sh;  ring  servi  :e  v snd<  r 
well  become  the  vehicle  for  imj  ementation  of  the  compi  1 • rs 
and  utilities  with  all  the  features  of  th-.e  standards. 

Note  that  many  of  the  features  mentioned  may  not  have  any 
implication  in  the  form  a language  tak<  • and  hal  ’feet 

(where  present)  may  differ  in  the  p robin::,  riented  a. 
procedural  languages.  It  h fell  for  c raj  Leteness, 

statement  of  functional  re j u3 remenl  ild  all-  ic  . - 

passing.  Tt  may  well  bo  that  fc  l opt  ion  of  tl  >e  fund 


requirements  as  a basic  standard  i • 


' ■ . ei  i t 


of  some  functions  as  hardware  »■  .•  ••  ‘ 


this  should  occur  is  just  • . v lid 


standard  language  should  c.mir  f 


!•  .-.•here  J is 


functional  requirements  di  . t-  nc:  e n Id:  •••  ; L v j y ,■<  ■ 


requirements  for  language  c q initii  n 1. 


•t.i  t.n  . n 


system  maintenance.  The  justi  Lcatj 


above . 
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P -:c?<  '1 ..  ■: ; i/o 

A.  Process  Measurement  input.' 

1.  M can : 

■i.  Scheduled:  0p<  n ; i all<  w th<  j :ific 

of  frequency,  grouping  and  phasing  f r a - 
input . 

It  should  be  possible  to  specify  a so  an  fre- 
quency or  processing  interval  for  eac!  in;.'. 
Completely  random  specification  of  fr<  ;u  y 
will  not  be  necessary  if  enough  diff  re., 
time  classes  are  included. 

It  should  be  possible  to  greu]  any  ;i van 
input  with  any  other  input  or  inputs  ■ ; 

they  are  scanned  consecutively. 

It  should  be  possible  t<  d5  tri  ite 
scannii  g < f the  inp  uts  in  i Lvei  ( : 
over  the  period  of  the  time  cI-ts  n 1 • at 
th<  scanner  is  nol  r aded  c<  ’tail  / ■ . 

For  example,  if  phasing  were  n 
system  containing  o,  , 1,  b . lb,  3o,  ■ nd 
-s  !C«  nd  1 1 me  cl?  , hey  w<  uld  all 
due  every  minute,  j ;sib Ly  :au  ing  ■ ; 
is  ’all  behind . ii  ■ , 1 rer,  mu  1 n 

interfere  with  the  ab<  vo  grouping  v-  ••luiromnn'!  . 
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b.  Demand:  It  should  "be  possible  for  inti  rrupl 

routines  or  other  programs  to  make  demand 
scan  requests  for  individual  or  multiple 
readings  of  any  points.  These  re quo  'l. 
should  he  done  as  2 on  as  i sil  • ft  r 
they  are  requested,  and  may  «.  ptiomlly  k 
precedence  over  regular  i-ylica  1 scan  \ in:  . 

Conversion  to  engineering  units  should  b 
optional. 

Valid at ion:  The  input  value  < f each  scanned 

should  he  checked  for  validity  limits  und/1  r 
illegal  configuration. 

It  should  be  possible  to  remove  m:  input  fr  :: 
or  limit  checking  when  it  has  failed  validity 
limit:  for  n c<  n • • -utivo  times,  wl  ere  n i • 
system  generation  parameter. 

It  should  be  possible  to  output  ••  message  v:it! 
the  out-of -limit  value  when  ••  point  has  failed 
validity  limits  n ccnsective  times. 

Conversion: 

•1 . C(  mj >ensatl( in:  in] iu1  readii  • hi  ild 

compensated  for  ser<  evTs'C  bef or.  -s  1 1 . ' 
convers  ioi  1 equations. . 
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b„  Standard  equations:  Provision  should  bo 

made  for  several  different  conversion 

equations.  For  example 

(1)  Thermocouples  including  the  following: 

Iron-Constant an 
Copper-Constant an 
Chromel-Constantan 
Chrome 1 -A lume 1 

Platinum  - Platinum  Rhodium  (10/') 

Platinum  - Platinum  Rhodium  (1;  ') 

Conversion  co-cff icients  should  be  suppli >d 
which  will  provide  errors  within  the  limits 
of  ISA  standard  C96.].  Input  readings  should 
be  compensated  for  thermocouple  reference 
before  conversion. 

(2)  Linear  conversion  of  the  f(  rm  MX  -)•  ! 

(?)  Polynomial  conversion 

(4)  Flow  conversion  incorporating  a : m av  - 
root  function 
a.  Liquid  Flow: 

Uncompensated 
Temperature  Compensated 
Gravity  Compensated 
Temperature  and  Gravity  Ccnpei  am 
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Id.  Gas  and  Steam  Plow 
Unc  omp  ens a t o d 
Pressure  compensated 
Temperature  Compensated 
Gravity  Compensated 
Combination  of  above 

(5)  No  conversion  --  readings  stored  as  read 

(6)  Special  equations:  user  should  have  tin 

ability  to  specify  any  conversion,  such 
as  table  look-up  for  code  conversions, 
and  to  relate  scan  frequency  to  filter 
and/or  conversion  processing  interval. 

4.  Filtering:  Each  input  should  have  the  option  of 

having  its  value  filtered  using  a digital  filter 
factor  specified  on  a point -by-point  basis.  The 
user  should  have  the  ability  to  specify  any  filter 
equations,  and  to  relate  scan  frequency  tc  filter 
processing  interval, 

5.  Alarming: 

a.  Each  input  should  have  the  option  of  having 
its  value  checked  against  both  high  and  lev; 
limits  and  a rate  of  change  limit.  When  1 imii 
violations  occur  it  should  be  possible  ta  : 

( 1)  pring  a message 

(2)  cause  the  execution  of  a program 

(3)  open  or  close-  a contact  (user  should  have 
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the  ability  to  r.pecify  the  list  of  e n- 
tacts ) . 

(4)  any  combination  of  the  above: 

B.  Process  Outputs 

1.  Two  common  internal  forms  of  outputs,  are 
absolute  and  incremental  values.  Both  forms  should 
be  supported. 

2.  Output  Generation:  The  generation  of  outputs  should 

allow  for  demand  outputs  or  the  specification  of 
frequency  and  phasing  of  each  output. 

3.  Conversion  from  engineering  units  to  count  - hue 

a.  Type  of  Conversion 

Conversion  equations  should  includ  s lea  t: 
Linear 
Quadratic 
Code  Conversions 


b.  Limit  Checking 

High  ana  low  Limits  should  be  check  d f<  r 
output  :alculated.  Violation  may  - 
provide  linkage  to  a specified  program  for 
appropriate  action. 

c.  Deviation  Limits 

Deviations  arc  defined  as  the  difference  between 
the  current  output  value  and  the  newly  caleul'tod 
output  value.  Maximum  absolute  deviation.-  r.ey 
optionally  be  specified  for  each  output  • ei  L 
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are  the  limiting  values  of  any  change  in  an 
output . 

If  the  deviation  limit  is  exceeded,  a progra 
linkage  to  a specified  program  can  he  estab- 
lished. Dead-hand  capability  should  be 
provided . 

C „ Event -Oriented  Input 

Interrupts  should  be  caused  by  changes  in  state  of 
single  bit  inputs  from  one  logical  condition  to  the 
other,  but  not  the  reverse. 
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1 1 1 . :LA  \ ri;v.  COMMUNICATION^ 


A. 


B. 


General 

1.  All  operator  I/O  rcquer.tr,  'hcaild  1 ' eokm  ./.led  ••  d 


within  one  second.  A response  c ild  be  ;ivei 
the  requester  to  indicate  either  a valid  or  In- 
valid request  was  made.  If  an  invalid  r 
has  boon  made,  the  system  should  indicate  th 
reason  for  trouble. 

. . Provision  should  be  made  tc  pr  the  pr  • 

operator  from  making  engineering  and  pr<  • . 
date  entries 

Process  Operator  and/or  Supervision 

1.  Active  entry  functions: 

These  operations  should  be  available  to  r 
operating  status  of  the  system.  T1  ii  ...  nl 
of  the  operator  entry  function. ••  should  bo  d>  u a 
such  a way  as  to  require  his  performing  ■<  •• 
additional  coded  (keyed)  actions  n >.c  i : 
the  possibility  of  inadvertent  entry  i ' or  . 
information.  All  parameters  available  J<  ■ 
operator  should  have  a range  of  acceptable  v- 
and  the  operator  should  be  notified  when  ! ' s 
is  not  within  the  acceptable  range, 
a.  Process,  I/O  scan — the  operate  r should  ! ■ 
able  to  activate  any  process.  I/1  p, 
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b.  an  Scan:  The  operator  should  be  allowed  to: 

( 1 ) Activate  or  deactivate  any  alarm. 

( ) Change  the  hi  ;h  and  low  alarm  .limit... 

Jhang  the  rate-of -change  limits. 

. ' hi  < : rat  or  she  uld  he  allc  wed  t < : 

( ) d d/delete  ■■  variable  t /fr  in  a log. 

meet  logs  r:  ■;  timed  frequency  > v on 
demand.  This  include.'  designation  of 
■.in  interval. 

d.  I* i*  nd  x’ocv  rding:  The  operator  should  be  allow- -d 

pecify  tlu  pen  number  and  variable  along 
v.'ith  tlie  desired  fro  money,  the  desired  ran  ;■ 
md  intercept. 

e.  Control:  Those  parameters  which  require 

knowledge  of  control  theory  and  timing  should 
not  be  considered  as  operator  function:-,  ho 
should  be  allowed  to: 

(l)  Change  the  set  point  of  a loop. 

(?)  Activate  or  deactivate  a loop. 

f.  Demand  Functions:  Certain  functions,  including 

user  application  programs,  should  bo  made 
available  to  the  operator  on  demand,  be  . liquid 
have  the  capability  to: 

(1)  Select  the  functions 

(2)  Specify  a specific  time  for  execution  ev 
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( v ) Specify  a time  interval  for  exeeuti  n or, 
(-1)  Demand  immediate  execution. 

(5)  Terminate  the  function, 
g.  Miscellaneous;  The  operator  should  he  able  to: 

(1)  Set  the  time  and  date. 

(2)  Activate  or  deactivate  selected  peri- 
pheral I/O  devices. 

(3)  Enter  pre-specif ied  process  data. 

. Passive  Entry  Functions: 

These  operations  should  he  made  available  to  in- 
terrogate the  operating  status  of  the  syst.it:  . 

a.  Process  I/O  scan:  The  operator  should  be  able 

to  list  or  display: 

(1)  The  status  of  a variable  (active/in- •■•tivo) 

(2)  The  value  of  a variable  or  of  a raw  data, 
input . 

(3)  The  identification  of  all  variables  de- 
activated from  the  scan. 

b.  Alarm  scan:  The  operator  should  be  permit  3 

(1)  List  or  display  the  alarm  statu"  of  any 
alarmed  variable. 

(2)  List  the  identification  along  with  limits 
and  value  of  those  variables  currently  in 


■■  > arm. 
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d. 


f . 


g- 


Logging:  The  operator  should  be  allowed  to: 

( 1)  Obtain  a list  of  those  logs  currently 
inactive. 

(2)  Obtain  a list  of  those  logs  currently 
on  automatic  request  along  with  the 
interval  for  each. 

Trend  recording:  The  operator  should  be  able 

to  obtain  the  current  status  of  each  trend 
pen  including  the  identification  and  present 
value  of  the  variable  along  with  its  range, 
its  intercept  and  its  scan  frequency. 

Control:  The  operator  should  be  able  tc  list 

or  display: 

( 1)  The  current  set  point  of  a loop, 

(2)  Whether  a loop  is  active  or  inactive. 

(3)  The  control  limits. 

Demand  functions:  He  should  be  allowed  to 

list  a menu  of  the  demand  functions,  their 
parameters  with  regard  to  demanding  a 
program,  and  status  (active/inactive). 
Miscellaneous --he  should  be  able  tc  demand 
the  current: 

( 1)  Time  and  date. 

(2)  Status  of  selected  I/O  peripherals. 

(3)  Value  of  preselected  process  data. 
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C . Control  Engineer 

1.  Active  Entry  Functions 

a.  Process  output:  The  control  engineer  u'd 

be  able  to  activate  or  deactivate  and  ccnfr>  ] 
any  digital/analog  device.  However,  tie  ■ 
actions  should  not  be  permitted  unless  - 
control  loop  corresponding  to  the  device  is 
deactivated . 

b.  Control:  The  engineer  should  bo  able  tv 

all  parameters  having  to  do  with  a *on:  -\  ! 1 . . p , 
such  as  algorithm  constants,  type  of  ; • rithti 
to  be  used,  maximum  allowable  change,  control 
frequency,  cascading  optings,  etc. 

c.  Process  I/O  scan:  The  engineer  should  V bio 
to  change  other  variable  parameters,  such  as 
as  scan  frequency,  conversion  eoeff  i'-ien 
validation  limit.-,  conversion  type,  filial- 
constants,  engineering  units,  flow  >n  eff.'  .-i mi  . 
type  compensation,  and  other  - as  necessary. 

d.  Data  age  checking:  He  should  be  all-  : 

(1)  Specify  any  variable  for  age  ciieoki 
a validity  check. 

(2)  Specify  the  age  limit  for  any  variabb- 
being  checked. 

. Pas.-,  jyo  Entry  Functions 


Digital  E/0:  The  engineer  ild  be  able  t< 
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obtain  a print-out  or  display  of  the  c nfig- 
uration  of  a specified  group  or  bit  (s). 

b.  Control:  He  should  be  able  to  obtain  a ist 

of  all  parameters  and  their  values,  having  t> 
do  with  a specified  control  loop. 

c.  Process  I/O  scan:  The  engineer  should  be 

able  to  list  and/or  display  the  value  of  any 
variable  parameter,  such  as  conversion  cn  - 
efficents , validation  limits,  ccnversi  n type, 
filter  constants  engineering  units,  fl  w 
coefficients,  type  of  compensation,  point  scan 
frequency,  and  others. 

Programmer 

1 . Active  Entry  Functions 

a.  The  programmer  should  be  permitted  tt  chang' 
the  contents  of  from  1 to  n consecutive 
locations  in  core  or  bulk  storage  through 
the  programmer's  I/O  device,  in  decimal 

and  in  the  number  system  used  by  the  systi  :■ 
assembler.  Any  changes  to  either  cc  re  r 
bulk  storage  should  be  accompanied  by 
print-out  of  the  contents  • f the  altered 
location( s)  “before  and  after  the  :hange. 

b.  The  programmer  should  be  able  to  cause  :.iv 
transfer  of  fr  m 1 to  n 1 cations  t.  /f r m e r 


X 
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or  bulk  storage. 

c.  He  should  be  able  to  read  (card  or  tape) 

and  store  1 to  n locations  into  core  or  bulk 
storage . 

Passive  Entry  Functions 

a.  The  programmer  should  be  able  tc  list  the 
contents  of  from  1 to  n consecutive  core  > r 


bulk  storage  locations  on  the  programmer’s 
I/O  device  in  decimal  and  in  the  number 
system  used  by  the  system  assembler, 
b.  He  should  be  able  to  punch  (on  cards  or  -uve) 
from  1 to  n consecutive  locations  of  cere  c r 
bulk  storage. 

Program  Loading  and  Linking:  The  programmer  she  ild 

be  able  to  load  (via  cards  or  tape)  and  link  pre  - 
grams  to  the  operating  system  on-line,  and  enter 
the  parameters  necessary  to  make  the  program  'av-  - 
tion  in  the  system. 
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IV.  OPERATING  SYSTEMS 

A . Interrupt  Handling 

1.  Definitions : For  the  purposes  of  this  specification, 

"interrupt"  shall  refer  to  suspension  of  the  ex- 
ecution of  a routine  as  a result  of  a hardware 

or  program  generated  signal.  Interrupt  handling 
is  the  procedure  which  the  operating  system  follows 
when  responding  to  an  interrupt. 

2.  Interrupt,  levels:  In  cases  where  the  hardware  con- 

figuration has  a number  of  interrupts,  the  operating 
system  should  be  capable  of  responding  to  those 
according  to  the  assigned  level  or  priority  of 

each  interrupt. 

3.  Interrupt  conditions:  With  respect  to  the  current 

routine  and  an  interrupt,  four  conditions  can  exist: 


a . 

Condition 

1: 

No  interrupts  are  present. 

Action: 

Continue  the  current 

routine. 

b. 

Condition 

2: 

Current 

routine  is  of  a higher 

priority 

■ than  the  interrupt. 

Action: 

Continue  the  current 

routine . 

c . 

Condition 

3: 

Current 

routine  is  of  sain*  pr.i  c 

rity  as 

interrupt . 

Action: 

Continue  the  current 

n utino . 


d.  Condition  Current  routine  is  of  a low -r 

priority  than  the  interrupt. 
Action:  Suspend  the  current 

routine  and  take  what- 
ever measures  are  nec- 
essary for  subsequent 
continuation,  then  proces 
the  interrupt. 

Interrupt  Processing:  In  processing  an  intermit, 

the  system  should  at  least  accomplish  the  foil  wing: 

a.  Since  it  is  impossible  for  an  executing  routine 
to  anticipate  the  instant  when  an  interrupt 
will  occur,  the  operating  system  should  suspend 
the  execution  and  save  whatever  data  is  required 
for  the  suspended  routine  to  continue  at  a 
later  time. 

b.  Take  necessary  steps  to  delay  processing  any 
interrupt  states  of  a priority  equal  to  ■,  r 
lower  than  the  currently  active  state. 

c.  Give  control  to  the  interrupt  response  j -• 
for  the  interrupt  currently  being  reccgni 


Program  Scheduling 

1.  Levels : The  operating  system  design  should  tv 

such  that  the  user  can  assign  priority  levels  fi  •* 
the  execution  of  application  programs. 

Enabling:  The  application  pr  ;rams  b<  l ■ 

to  onable/disabio  the  interrupt  system,  a 

to  the  extent  of  controlling  interrupt  <•>  niwctii  i. 
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to  other  application  programs. 

5.  Realtime  Clock,  Power  Fail-Restore:  The  system 

interrupt  structure  should  give  highest  priority 
to  the  power  failure-restore  interrupt,  if  this 
option  is  provided.  Next  highest  priority  should 
be  assigned  to  the  system  realtime  clock.  All 
other  peripheral  and  process  interrupts  should  be 
of  lower  priorities. 

4.  Execution  Priority:  All  programs  are  assigned  an 

execution  priority.  When  more  than  one  program,  is 
scheduled,  the  comparison  of  these  priorities  i: 
the  determining  factor  for  one  program  taking  } ■■■  - 
cedence  over  another.  The  operating  system  priority 
structure  should  be  designed  such  that  interrupts 
and  programs  are  merged  into  the  overall  priority 
scheme  to  insure  that  use  of  computer  time  is 
handled  on  a priority  basis. 

5-  Execution  Scheduling:  It  should  be  possible  to 

schedule  the  execution  of  a program  in  one  of  the 
following  ways : 

a.  Interrupt  active:  when  recognised,  schedu1-. 

the  execution  of  a program. 

b.  Passage  of  time:  it  should  bo  possible  tu 

schedule  the  execution  of  a program:  m a t.h  - ; 
frequency  or  at  a time  of  day.  The  re  uv  .'1  r 


— 
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should  be  able  to  specify: 

( 1)  time  of  day  for  execution, 

(2)  time  increment  for  execution  with  a starting 
time,  and 

(?)  execution  priority 

c.  Program  request:  An  executing  program  should 

be  able  to  schedule  the  execution  of  another 
program.  It  should  be  possible  for  the  re- 
questing program  to  specify  the  execute 
priority  of  the  requested  program.  With  this 
capability,  the  requesting  program  should 
have  the  following  options  available  for 
scheduling  the  execution  of  requested  program.  -. 

( l)  immediate  execution  (higher  priority) -- 

with  optional  return  to  requesting  program 
after  completion. 

(?)  deferred  execution  (lower  priority)  -- 
with  no  return  to  requesting  prograt . 
Execution  of  requested  pregran  folh  ■: 
completion  of  the  requfesting  progran . 

d.  Program  Suspension:  Discontinue  pregr  ;:: 

ecution  for  a specified  time  interval,  without 
disturbing  the  logical  continuity  of  the  i rc- 
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C . Memory  Utilization 

1.  Allocation:  The  operating  system  should  have  the 

capability  of  dynamically  allocating  and  assigning 
available  core  for  temporary  use  to  requestors. 
This  allocation  should  be  done  according  to  a re- 
questing priority.  When  requesting  core,  the  re- 
questor should  be  able  to  specify: 

a.  amount  of  memory  needed 

b.  priority  of  request  for  memory 

The  operating  system  should  then  satisfy  requests 
for  memory  allocation  according  to  the  requesting 
priority. 


Allocatable  memory  may  be  partitioned  according  to 
program  priorities  and  high  priority  memory  would 
not  be  available  to  lower  priority  requestors. 

The  actual  dimensions  of  partitions  would  be 
installation  parameters  and  should  be  done  in 
such  a way  as  to  make  memory  available  to  satisfy 
the  needs  of  higher  priority  requestors  first,  and 
thus  maintain  the  overall  integrity  of  the  priority 
scheme. 


It  should  be  understood  that  a requestor  returns 
allocatable  memory,  since  the  operating  system  can- 
not sense  when  the  requestor  is  finished  with  it. 

2.  Roll-out:  v ry  ■ ftei  the  need  develops  t<  execute 

a high  priority  program  while  allocatable  memory  is 
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occupied  with  lower  priority  programs.  When  this 
occurs,  the  operating  system  should  be  capable  of 
suspending  and  saving  the  lower  priority  programs, 
freeing  allocatable  memory  for  higher  priority  use. 

D . Input/Output  Handling 

1.  General:  The  operating  system  should  include  the 

necessary  drivers  to  operate  all  I/O  equipment 
(process  and  non-process)  which  might  be  included 
in  the  system. 

2.  I/O  Requests:  Should  have  the  following  characteristics 

a.  Consistent  format:  The  requirements  for  making 

I/O  requests  should  be  organis.ed  in  a consistent 
format.  The  syntactial  conventions,  which  must 
be  followed  by  requestors  should  be  consistent 
throughout  for  all  I/O  requests. 

b.  The  requestor  can  specify  an  I/O  device  in  a 
symbolic  way.  It  should  not  be  necessary  for 
the  requestor  to  know  a device  number  and  other 
hardware  characteristics  peculiar  to  a device, 
such  as  channel,  line,  and  equipment  numbers. 

c.  Priority:  Requestor  specifies  the  priority  at 

which  the  request  is  to  be  serviced.  This  is 
done  at  execution  time. 

d.  I/O  List:  Requestor  specifies  symbolically  the 

location  of  the  I/O  list. 

c.  Completion:  Requestor  should  have  the  option 
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suspend  ing  execution  of  the  calling  program 
until  the  completion  of  I/O. 
f.  Buf fered/non-buff ered : Where  available,  the 

requestor  should  be  able  to  specify  that  I/O 
be  accomplished  either  buffered  or  non-buff ered . 

3.  Processing  I/O  Requests:  The  operating  system  should 

be  the  interface  between  I/O  requests  and  the  device 
drivers.  Checking  the  validity  of  I /o  requests  and 
insuring  that  they  are  satisfied  in  order  of  prio- 
rity are  functions  of  the  operating  system.  Con- 
versely, the  requestor  should  not  be  required  to 
take  any  action  which  might  involve  status  checking 
or  I/O  timing  considerations. 

E . Background  Processing 

1.  Definition:  A background  program  is  defined  in  the 

glossary  as  a program  of  no  particular  urgency  with 
regard  to  time  and  which  may  be  pre-empted  by  a 
program  of  greater  urgency  and  priority. 

2.  Job  Processor:  If  the  operating  system  includes 

background  capability,  the  job  processor  should  be 
called  or  scheduled  on  a demand  (interrupt)  basis 
by  a user. 

The  job  processor  should  have  control  of  all  pro- 
gram development,  debugging,  and  other  utility 
programs  available  to  the  user. 
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In  addition  to  having  control  of  vendor-provided 
utility  programs,  the  job  processor  should  be 
capable  of  creating  and  maintaining  a library  of 
background  programs  generated  by  the  user.  The 
background  job  processor  should,  by  the  nature  of 
the  function  it  performs,  operate  at  the  lowest 
priority. 

F . On-Line  Diagnostics 

1.  Definition:  Most  computer  programs  employ  a 

measure  of  dignostics  to  test  for  system  malfunction:-. 
For  this  specification,  diagnostics  considered  are 
those  which  the  operating  system  performs  in  order 

to  maintain  a properly  functioning  system. 

2.  Request : The  operating  system  should  verify,  in  si 

far  as  practical,  the  parameters  required  by  requests 
to  the  system.  When  the  system  detects  an  error 
condition,  it  should  take  the  necessary  action  to 
protect  the  system  and  communicate  the  error  condition 
back  to  the  requestor. 

3.  Timing:  All  events  should  have  a timing  conrtr  . : 

placed  upon  them.  This  would  be  a parameter  defined 
at  load  time.  The  operating  system  should  take 
action  to  terminate  the  event  when  the  time  limit 

is  exceeded.  This  commonly  occurs  when  an  I/C 
device  fails  and  leaves  a program  suspended, 
waiting  for  completion  of  I/O  or  when  a program 
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hangs  in  a loop. 

4.  I/O : The  operating  system  should  provide  for 

suitable  alternative  action  to  be  taker,  whenever 
a primary  device  fails.  Ordinarily,  this  action 
would  not  involve  notifying  the  requestor.  ’ owev 
if  the  situation  is  irrecoverable,  the  requestor 
should  receive  some  indication  of  the  condition  i 
order  that  he  might  take  some  additional  actio-  . 

5.  Recovery:  The  operating  system  should,  on  regul- 

intervals,  make  some  diagnostic  checks,  such  as 
checking  system  constants,  to  determine  that  the 
operating  system  is  intact.  It  should  have 
automatic  recovery  capability  to  be  used  whenever 
unusual  or  abnormal  conditions  are  sensed  within 
the  system. 

G.  Expandability 

1.  Modularity:  The  system  should  be  designed  and 

organized  with  the  expectation  that  it  will  be 
expanded.  The  user  should  have  options  available 
to  organize  a system  to  meet  his  particular  re- 
quirements while  minimizing  the  inclusion  if 
functions  which  he  does  not  require. 

P.  Field  Expansion:  Field  expandable  hardwire  ■■  ■ - 

pcnerits  should  be  supported  by  comparable  .-nera' 


e r . 


system  expandability. 
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G YG  TEM  GENF.D  AT  I ON 
A.  Introduction 

System  Generation  (definition): 

"The  task  of  establishing  an  operational  system 
composed  of: 

a.  installed  hardware, 

b.  vendor-supplied  programs,  and 

c.  those  programs  written  expecially  for  the  ap- 
plication , which  will  be  expected  to  fun 

in  either  foreground  or  backgroud  mode  . 1 e 

application  computer,  while  the  process  is  in- 
line . " 

ertain  utility,  diagnostic,  or  various  other 
categories  of  programs  and  any  special  hardware 
required  by  them  may  also  be  operational  in  the 
background  mode  or  when  the  application  computer 
is  off-line. 

Program  Development  is  the  series  of  steps  betweei 
defining  the  problem  and  having  a fur. ‘tin  in  pr<  - 
gram.  Testing  and  debugging  begin  when  the  pro  v 
has  been  prepared  in  source  form. 

Gome  programming  errors  are  detected  when  the  pm  - 
gram  is  compiled;  others  require  execution  of  the 
program,  possibly  with  simulated  inputs  and  out put: . 


traces  and  dumps,  before  yielding  to  detect!  r. 
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c.  Test 

i ; : Botl . p art  ia3  and  - mj  Lete  sys 

(1) 

1 i adi ng  ( and  linking  as  re  qui  red ) ; 

(?) 

S imul a t i or  of  p r oc  e s s. ; 

(5) 

Tracing: 

(a)  Arithmetic 

(b)  Logical 

(J0 

Debugging 

Vendor-Pupplied  Programs 


Customizing  vendor  software  to  needs  of  a spec  ifi 
application.  The  program-development  progr-  : 
compilers,  assemblers,  loaders , emulators,  el  . 
The  on-line  programs,  operating  systems,  s a- 
packages,  etc. 

a.  Remove  modules  which  are  not  applicable, 
device  drivers  not  used,  conversions  not  used 
ect . 

b.  Supply  special  information  about  hardware  C'-n 

figuration  (see  also  D,  Linking  Software  tc 

Hardware),  examples  are: 

core  size; 
disk  capacity; 
tape  configuration; 
input  options; 
output  options; 
interrupt  trap  addresses; 
special  indexing  addresses; 
other  special  use  locations; 

data  acquisition  options  (direct  memory  acces 
etc. ) ; 

signal  conditioners 

(l)  logical  inverters 
(?)  shifters 
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C . Loading 

1.  There  should  be  the  ability  to  generate  object 
coding  with  appropriate  "header"  infer:  aticn  sc 
that  subsequently  the  object  code  can  be: 

a.  Loaded  in  core  as  compiled  with  minimal  i - 
struction  from  its  header; 

b.  Loaded  in  next  available  core  (considering  pi  ••  :• . 
odd,  even,  et-'.); 

c.  Loaded  in  c< re  i fter  a i It  pending  an  on- 
line origin  directive; 

d.  Loaded  in  object-image  onto  secondary  memory 
as  directed  in  header; 

e.  Loaded  as  in  1 d * except  in  "next  available 
merit"  of  secondary  memory; 

f.  Loaded  as  in  Td'  except  after  a halt  pendin  • 
an  on-line  origin  directive. 

2.  There  should  be  the  ability  to  copy: 

a.  Relocatable  program  images  fror  second-  gy 
memory  into  reloadable  form  or.  compatible  ii  - 
put  media; 

b.  Data  images  from  secondary  memory  n lat 

form  on  compatible  input  media. 

There  should  be  provisions  t<  re  ad  previ<  islj 
dumped  relocatable  pia  gram  images  -iirI  dot" 
into  secondary  men  < -ry  lo  ginni:  ; --t.  n-  < • 1 " • (i 
: t a r t ing  1 oc  a t i on  s , 
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There  should  be  provisions  to  load  compiled  n - 
locatable  program  images  and  compiled  or  ass*.-:  .bled 
data  images  onto  secondary  memory  at  a suitable 
starting  location. 

Linking  Software  to  hardware 

Ability  to  inform  the  system  through  a mechanic:  , ich 
as  a symbol  table  available  to  the  compiler,  of: 

1.  The  physical  termination  identificat.  n of  each 
peripheral  industrial  application  component 
(process  I/O  device)  with  which  it  must  coir.ru:.  1 
(sample  specification  statement) 

Program  Identifier  - Physical  Termination  Ident- 
ifier (ID) 

. The  physical  identity  of  the  communication  ct.v  ; c" 
over  which  information  will  be  exchanged  wit':  eac 
industrial  applications  component:  (Cample  speci- 

fication statements) 

Program  Identifier  =*  (industrial  application  nn- 
ponent)  via  (communication  channel,  identifier) 

Data  to/from  (industrial  application  component) 
via  ( communicati on  channel,  identifier) 

3.  The  physical  identification  of: 

a.  each  separable  interrupt  level  and  its  progr  c: 
identi f lor; 

b.  eac  separable  interrupt  j ini  al  ;iv< 
arid  'ts  program  identifier. 
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E.  Language -to-Language  Linking 

In  order  to  provide  maximum  flexibility  to  the  pro- 
grammer, he  should  be  allowed  to  ch<  se  1 '•  ••  Langu  ;< 
best  suited  to  stating  the  task  to  be  performed, 
should  be  permitted  to  interix  these  language 
statments  within  one  program. 

1.  Industrial  Process  Language  to  Assembler; 

Industrial  Process  Language  to  Problem  < ri<  J 
Languages ; 

5.  The  Industrial  Process  Language  Compiler  should 
tolerate  "Foreign"  statements  in  the  above  langu \ 
and  permit  the  Assembler  and  other  Compiler  tc  an 
a^yze  these  for  correctness,  etc. 

F . Areas  of  Improvement 

1.  Greater  modularity  of  software 

a.  Operating  System  Software 

b.  Other  Packaged  Software 

The  vendor  documentation  of  these  packages  should 
be  adequate  for  determining  how  to  remove  ■'  arl 
modules  and  associated  subroutines  which  the  user 
may  not  require  in  his  system. 

. There  should  be  ••  twc  -way-***  try  method  f d<  ■ 
whether  a subroutine  can  be  dropped  from  1'  < * ' • - 

ra  ry,  i . e . , by  subrcn i ; e,  vrt  al  tasks  us«  it , 
by  task,  what  sul  routines  are  used. 
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Kxamples  of  modules  are: 

a.  I/'  drivers 

b.  Data  conversion  routines 

c.  Scan  programs 

d.  Format  conversions 

e.  Arithmetic  subroutines 

f.  Parameter-passing  options 

A system  generation  scheme  is  required  for  s- all 
object  systems,  such  that  the  object  system  • 
be  generated  on  some  other,  larger  system, 
larger  system  may  be  located  locally,  or  re;  - a- 
treat  the  o\  Je  ■ ' maohi no , ar.d  bo- 
make  or  model  from  the  object  machine. 
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VI.  SYSTEM  MAINTENANCE 

A . General 

Reliability  and  maintainability  are  interacting  char-, 
teristics  in  a system  and  result  in  a single  feature: 
system  availability.  The  implementati  r.  v f system 
maintenance  depends  on  the  availability  r<  julri 
the  system,  and  the  extent  of  the  task  depends  t n the 
reliability  of  the  component  parts.  In  the  secti  is 
that  f<  Llow,  ■ Lmj  em  tati  n f maintenanc<  is 
ommitted  on  the  > ois  that  it  is  peculiar  tc  a syst 
and  musl  l dev  i J for  that  particu  r sy  st  ■:  . 

The  c bjective  wi  12  t rgani  pre  nti  m i 
pr<  'ran  wh  tr<  n J nanc  Li  • schedu  i basj 

rl  s ess , pr  vi  sion  si  d 1 for  diagi 

aids  t«  allow  rapid  re]  i 'ai  fuipn 

The  remainder  of  this  secti  u assumes  t.’n-  us- 
planned  preventive  maintenance  . 

B.  Hardware  Maintenance 

1 . C.P.U.  and  Standard  Poripher.a  1 s 

Diagnostic  1 sstlng  pr  grams  s-!ia  : ■ ■ ■■ 

the  C/P.U.  and  standard  peripht  r< 

the  basic  vendor-supplied  equipment,  to  is  >■  • i 

regarded  ns  a mandat  ry  require!)  . Tt.  1 s - 

sirable  that  tw<  l’t  rms.  » f t st  1 ■ • v.ni  • : 

a . f imp! i ■ on-  is.''  f au  l.  ’ «i  : ■ at  ! •.  • . . 

b.  ’■  mp rehensive  off-  : • ’ lii  ; pr 
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• Process  [equipment 

Diagnostic  programs  should  be  preyi ded  f*  r t! 
process  equipment  under  computer  •■ctitn. 
this  may  be  an  equipment  logging  end  moniti  r 
system.  As  a minimum,  the  faulty  c.ontri  ! 1c 
sb.ould  be  indicated,  and  in  sor.e  c incur. si  ■ a 
may  be  desirable  to  pinpoint  the  faulty  e : u i ] 
i.e.,  valve,  sensor,  etc. 

Fconomic  Preventive  Maintenance 
To  ensure  that  the  preventive  maintenance  nr. 
is  carried  out  economically,  it  ir  suggest'  '; 
the  logging  and  monitoring  system  be  use  ; ‘ 
develop  operational  reliability  date  . tho  ' 
stallation  and  that  this  data  should  be  used 
modi  i'y  tl  e ma i ntenanc< • sh  :edul • • . 

1 . n.puter  Assisted  Maintenance 

t may  be  desirable  to  implement,  on  a • pui 
programs  that  will  supply  or  process  dat  ■ tc- 
n I tenance  perse  nnel  ti  their  ; sks , e.g. , 
ely  equ ipir < rt  faults , sug  jest  ! ■ tyj 
a in t enance — repair  or  rep 1 ace , etc , 

. ' ; ■ i re  P a r t r T n vent cry 

This  could  usefully  be  perforti  od  by  a u : ■ ' 
P'tock  levels  to  be  held  could  be  nr  du-ed  • .• 

■ ■ . c f sr,  based  n quat  t i i y ii  use,  ps  ■ ■ Li 
history,  and  > rder  lead  time. 
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C • Software  Maintenance 

Adequate  provisions  must  be  made  t«.  protect 
integrity.  Controls  should  be  buill  ini 
to  restrict  the  ability  to  destroy  i--tu  r pr  ■ : 

Similarly,  the  incorporation  f pr<  h"  1 •••  vl 

updates  must  be  organized  t.  reduce  th>  ] . ' ' • 

erroneous  or  incompatible  software  ■ \\J.  t‘-  : : • 
system. 

The  implementation  of  software  tv  h-aui  ;e  the  - 
machine  interface  should  be  such  -is  t minimi 
possibility  of  the  operate  r carrying  cut  u.  u ri 
operations  (while  this  is  primarily  ir  "bed  f >■  ] r 
and  personnel  safety  reasons,  improj  r < ) •••rati  t. 
equipment  may  reduce  reliability).  If  it  i.  y . i; 
in  a system  to  reroute  a device,  (o.g.  , a • nr.  h r 
output  fails  and  there  is  a spare  output  aval  ), 

then  it  should  be  possible  tv  easily  amend  th-  - 
ference  to  that  device. 

On-line  routines  shall  be  available  to  allow  initi- 
alization if  replacement  "quipment. 

D . Document at i • n 

Basic  tc  any  maintenance  function  is  the  sysl 
d<  cum< sntat ! on . N te  also  that  t ; i ; s cumenl 

must  bo  maintained  f.«  rof ! ect  th«*  "urr  . : 
the  hardware  and  software  thre -ugh  ut  th"  1 


of  the  system. 
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The  following  list  constitutes  a minimum  documental,!  . 
package  that  should  he  provided  with  a system: 

1.  System  Description  and  Objectives 

2.  Reference  Manuals 

3.  Design  Specifications 

4.  Acceptance-Testing  Documentation 

5.  Warranties 

6.  Hardware  Maintenance  Handbooks 

7.  Contract  Maintenance  Schedules  (if  used) 

8.  Spare  Parts  Lists,  Prices  and  Sources 

9.  Programming  Manual 

10.  Program  Descriptions 

11.  Program  Listing  and  Flow  Charts 
1,  . Initializing  Procedures 

13.  Operating  Procedures 

14.  Program  Sources  (Users*  groups,  authors,  etc.) 
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VII.  CONTROL  COMPUTATION 

Means  should  he  provided  for  mathematical  computation:' 
including  at  least  the  operators  for  addition,  subtract!  n, 
multiplication,  division  and  exponentiation  and  for  1 > g:  " 1 
operations  and  decisions.  The  remainder  of  the  section  :! 
primarily  aimed  at  specifying  functions  necessary  for  a 
problem  oriented  language.  The  underlying  requirement  v 
this  section  is  that  a knowledge  of  the  computer  operating 
system  should  not  be  necessary  to  construct  control  schemes. 

A . Control  Loop  Servicing 

1.  It  should  provide  control  at  a frequency  corre  - 
sponding to  the  frequency  of  acquisition  of  in- 
put data  for  a control  loop. 

2.  It  should  provide  control  at  a frequency  corre- 
sponding to  a sub-multiple  of  the  frequency  < r 
acquisition  of  input  data  for  a centre]  lot}-. 

3.  It  should  provide  control  at  a frequency  ind'.av  - 
dent  of  the  acquisition  of  input  dat'  . 

4.  Control  computation  for  a computer  control  hep 
should  be  such  that  the  time  between  the  . • u 
and  the  control  output  for  n given  loop  is  ai 
minimum. 

B.  Control  Loop  Cener.atic  n 

Control  loops  should  he  constructed  using  modular 

function  blocks. 

a.  libraries  of  control  algorithm:’,  limil  •»}.. 
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algorithms,  filter  algorithms  and  output  al- 
gorithms should  be  provided. 

b.  both  incremental  and  positional  control  algo- 
rithms should  be  available. 

c.  the  user  should  have  the  ability  to  construct 
algorithms  beyond  these  supplied  with  the 
system. 

C . Data  Base 

A structured  file  should  be  provided  for  specifica- 
tion or  storage  of  control  loop  information  such  as: 

a.  input  variables 

b.  messages 

c.  common  data 

d.  constants 

e.  control  loop  cascading  specifications  such 
that : 

1.  the  operator  may  connect  or  disconnect 
cascade  at  any  level 

2.  it  should  be  possible  to  connect  or  dis- 
connect cascade  on  request  from  a higher 
level 

3.  should  the  intermediate  level  if  car. -ado 


be  disconnected,  higher  levels  may  op- 
tionally be  disconnected  as  well 
A means  of  easily  accessing  and  modifying  information 
in  the  file  should  be  provided  through  the  opera;, or*. 
I/O  devices,  the  system  I/O  devices  and  high  level  ] r - 
grams . 
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VIII.  INTERCOMPUTER  COMMUNICATIONS 

A . General 

1.  Hierarchical  systems,  vertically  organised, 
will  consist  of  "mother"  and  "daughter"  system;. 

The  "daughter"  systems  will  be  defined  as  th-  so 
of  higher  dynamic  requirements , and  will  usually 
be  sensor-based,  and  smaller  in  sice  and  cost  than 
"mother"  systems.  "Mother"  systems  will  ordinur'  ly 
be  management-oriented,  but  may  also  be  involveu 

in  direct  operation  of  production  or  testis,  g 
equipment. 

2.  Parallel  systems,  horizontally  organized,  will 
consist  of  either  "mothers"  or  "daughters", 
with  approximately  equal  dynamic  requirements. 

B.  System  Discipline 

1.  System  integrity  is  of  primary  importance  si 
means  must  be  provided  for  error  detection. 

Failure  of  one  element,  such  as  a daughter 
component,  should  not  cause  a cascading  of 
failures  throughout  the  hierarchy.  Local 
power  failures  or  other  failures  must  be  n ‘ 

"by  adjoining  elements,  even  though  normal  eg 
communications  (or  control  < f *omr.unicati  • i ) 
may  be  one-way. 

2.  System  generation  methods  will  be  used  f 
structure  the  hierarchy,  t»  determine  bl  <•  us  e 
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of  control  of  data  transmission  for  ther  th:  a 
fault  conditions. 

Logic  must  be  provided  t<  synchr*  ni  e the  tin 
of  day  between  computers. 

I.  Illegal  requests,  such  as  attempts  t<  write 

into  protected  areas,  or  to  overflow  buffer  boun 
daries  should  be  detected  and  prevented. 

C . Hardware  Capability 

1.  A minimum  capability  shall  consist  f ability 
to  transmit  or  receive,  half-duplex. 

2.  Capability  shall  be  provided  for  at  least  1 ry 
and  ISO,  or  binary  and  ASCII. 

D . Software  Capability 

1.  The  same  general  procedures  are  to  be  used, 

whether  the  computers  are  local  or  remote  fr  n: 
each  other.  System  generation  should  accommo- 
date timing  restrictions  due  to  distance  and 
transmission  modes  for  each  channel  used. 

?.  Software  for  data  transmission  should  not  d:' 

tinguish  between  transmission  of  data  and  tran-- 
mission  of  programs. 

a)  Capability  should  be  provided  for  trans- 
mission of  either  random  or  sequential 
data . 

a.  Data  transmission  to  other  computers  should  1 
handled  in  a manner  similar  t<  methods  used 
for  hand  ing  other  peripherals  in  the  system. 


4.  The  ability  to  output  messages  to  a remote 
computers's  peripherals  is  required.  This  type 
of  request  should  take  the  form  of  standard  I/( 
statements . 

5.  The  option  to  either  continue  a pr<  *.* illii 

for  data  transfer  or  waiting  until  the  t :•••  -ii  -• 
is  completed  should  be  provided. 

Remote  Task  Selection 

1 . pr  vision  rust  be  made,  f<  ••  •••  • te  • ntr 

•'  e mputer  task  selection.  For  example,  d t 
received  may  be  intended  for  a file,  >•  it 
be  a program  or  request  fcr  a program  t.  bo 
• ecul  d . .’ye ; 1 ■■  nit<  rs  must  1 w 

t<  x mine  • mj  eted  data  trar  smission  t< 
s t rmine  the  end  -usi  f J ■ d it  . 

c . Transmission  Jontrol  Characters 

a)  A standard  control  character  or  control 
character  string  format  must  be  defines 
as  part  of  the  implementation  of  high 
level  industrial  computer  languages. . 
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TX.  FILE-:  MANAGEMENT 

A comprehensive  system  for  management  of  the  large  an.  ur.t 
of  data  (including  program  files)  should  have  the  following 
characteristics : 

1.  The  ability  to  define  files  to  the  operating  system 
while  causing  their  creation  by  means  of  a mainter.-  n.- 
or  utility  program. 

The  following  items  should  be  available  as  defining 
parameters  for  creation  of  files: 

a.  Label:  either  a number  or  character  string  . 

b.  Device  on  which  the  file  will  exist 

c.  Type  of  file: 

(1)  Organisation: 

Sequential  access,  or 
Random  acess 

(2)  Record  type: 

Fixed  length,  or 
Variable  length 

(3)  File  type: 

Fixed  length,  or 
Dynamically  expandable 

d.  File  Sixe 

( 1)  number  of  records  for  a fixed  length,  or 

(2)  initial  number  of  records,  plus  incremental 
number  of  records,  plus  maximum  allowable 
number  of  expansions  (increments)  iVr  dyn  i b 


r 
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expandable  files. 

e.  Record  Size 

(1)  number  of  words/characters  per  record,  for 
fixed  length  records,  or 

(2)  maximum  allowable  number  of  words/charactc •■■■ , 
for  variable  length  records, 

(2)  Blocking  factor 

f.  File  integrity 

(1)  Dynamically  definable  protection  via  "open'' 

and  "close"  types  of  executable  statement.;  of 
application  programs. 

(a)  "Open"  file,  with  the  following  item.- 
parameters : 

File  name  or  number 
Definition  of  status  as: 

Reserved  for  exclusive  use  of 
"opening"  program.  (puts  file  ini. 
"protected"  status  for  all  other 
programs ) 

"WRITE"  reserved  for  "opening" 
program  (places  file  into  "road-,  nly” 
status  for  all  other  program.') 

Unlimited  access  for  any  pn  grar 
Error  return,  for  the  following  einti.i'.i  ’ : 

f i le  nono.xistwco 
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file  currently  open  with  a conflicting 
status . 

( b)  "Close"  file,  with  the  following 
items  as  parameters: 

File  name  or  number 
Error  return  condition.-  as  fol- 
lows : 

File  r.<  r.existant 

(2)  Fixed  definition  f pri  tectieg  for  life 

of  file,  with  the  f>  Hewing  options: 

(a)  Read-only  by  any  program  except 
utility/maintenance  system 

(b)  Unprotected  - available  for  read/ 
write  use  by  any  program. 

2.  The  ability  to  remove  or  delete  files  by  means  of  a 
maintenance  or  utility  program,  in  such  a manner  that 
inadvertant  deletion  is  difficult. 

3,  The  ability  tc  copy  files  from  the  device  on  wh3  ■'  '- 

resides  to  another  device  without  destroying  the  < rig' 
file,  by  means  of  a maintenance  or  utility  prc , ;r-u  . 

4-.  The  ability  to  optimise  location  of  storage  alii  -at-  a 
to  files  by  means  of  a utility  or  maintenance  pr< 
e.g.  moving  files,  not  stored  contiguously,  inti 
continguit.y. 

The  ability  t a - •>  Logical  rec<  rds  in  • f ' 
means  of  the  following  types  of  executable  s,-t—  ■ 
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in  application  programs,  with  return  of  error  in- 
formation to  the  application  program  (in  such  cases 
as:  file  non-existance , attempted  acess  of  a elcsed 
file,  attempted  write  to  a "read-only"  file,  access 
attempted  beyond  range  of  file,  and  attempted  access 
of  a "protected"  file) ; 

a.  "READ"  a logical  record  from  the  file  into  a vari- 
able or  list  of  variables  specified  in  the  statement. 
(Subject  to  file  integrity  specifications) 

b.  "WRITE"  a logical  recrod  from  a variable  or  list 

of  variables  specified  in  the  statements,  ti  a fils. 
(Subject  to  file  integrity  specifications) 

Definitions : 

FILE:  An  organcied  structure,  consisting  <. -a 

arbitrary  number  of  records,  for  storii.  :n- 
formation  on  a bulk  storage  device,  e.s., 
disk,  drum,  core,  tape. 

RECORD : A segment  of  a ; U :onsisting  f 

arbitrary  number  of  words/characters. 

Logical  Record  - A record  organised 

cording  ti  its  aprl  icais:  > 
treated  as  ■ If 
entity. 

Physical  Record  - A r<;c>  rd  sized  \ r 

fie lent  transfer  « f in- 
•'  rmati  * n betwi  s >:  v ‘ • 
and/or  efficient 
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utilization  of  storage 
cp  ;ee  on  - device. 

BLOCKING  FACTOR;  the  number  of  logical  re  ■ 

per  physical  record. 


-59- 

SECTION  II 


FUNCTIONAL  REQUIREMENTS  FOR 
LANGUAGE  FEATURES  FOR  A 
PROCEDURAL  LANGUAGE  FOR  INDUSTRIAL 
COMPUTERS 


Subsequent  to  the  appearance  of  the  general  functional 
requirements  reproduced  just  previously,  the  Long  Term 
Procedural  Languages  Committee  modified  and  extended  them 
specifically  for  the  LTPL . These  are  the  "green  sheets" 
which  are  frequently  discussed  in  later  Minutes  of  the 
Workshops.  They  were  published  on  pp . 77-101  of  the  Sixth 
Minutes  of  the  Purdue  Workshop  on  Standardization  of  Industrial 
Computer  Languages . 


PafiCuDLG  AAit  tLXNK-NoT  PILMaD 
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FUNCTIONAL  REQUIREMENTS  FOR 

LANGUAGE  FEATURES  FOR  A PROCEDURAL 
LANGUAGE  FOR  INDUSTRIAL  COMPUTER:; 

(Adopted  by  the  Workshop  on  Standardisation 
of  Industrial  computer  Languages  - October  29,  -;,-V  ) 

INTRODUCTION  I 

As  functional  requirements,  these  facilities  must  be  • .-id-  I 

ered  to  represent  a minimum  capabil ity  which  must  br  avail"' 
the  user  of  the  language;  ther  facilities  wl  sun  y • ] r vid 
as  language  design  ensues.  Additional  functi  nal  r<  juir  • nts  wl 
result  from  wo. rk  n acceptance  criteria,  hardware/s  ftw  re 
and  program  mans  ;ement.  (It  should  be  ns  t<  d that  th<  ■■  ra  :1  1 • 
impact  of  functional  requirements  is  that  they  represent  desig 
criteria  t;  which  the  language  designer  must  address  himself). 

During  the  development  of  the  functional  requirements  f'  r 
tasking.  interrupts,  event  . and  s maph  res,  it  was  necessar 
devi  r fairly  f rma ] exeeutl  i n dels  t understa  ■ J funct j 

a]  requirements;  these  m lels  are  inc  ud  d ii  thi  plan: 

these  functional  requirements  and  are  not  as  a required  f rr 

■ mp  ementati  ..  F r examj  I 1 ■ , explanat  1 f taskit  ; f r t r 

might  be  possible  with  a simp  ■ • r im  del. 


rnaCEDlNG  PAIL  BLANK-HOT  PIL4LD 
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1. 

Interrupt  Handling 
And 

the  Synchronization 
Of 

Parallel  Computational  Processes 


INTRODUCTION 


Effective  handling  of  interrupts  and  asynchronous  and  parallel 
computational  processes  is  a primary  requirement  for  a real-time 
language.  This  section  outlines  those  facilities  required  for  a 
procedural  language  for  real-time  industrial  computers  for  interrupt 
handling  and  synchronization;  another  section  will  outline  tasking 
requirements . 

Execution  Model 

In  order  to  determine  functional  requirements,  we  will  first 
explain  the  general  execution  model  assumed.  (The  attempt  is  to 
make  this  discussion  "free  standing"  - definitions  are  from 
Multics ) . 

A sequence  of  statements  which  may  be  executed  by  the  CPU  is 
a segment . A computational  process  exists  when  a processor  is 
executing  instructions  from  some  segment.  Many  computer  systems 
have  the  capability  of  executing  several  computational  processes 
simultaneously.  This  may  happen  on  a single  processor  system  when 
one  process  must  wait  for  an  I/O  operation,  for  example,  and 
another  process  can  proceed  with  useful  work.  When  this  happens, 
parallel  computational  processes  are  occurring. 

In  general,  parallel  processes  proceed  with  no  defined  re- 
lationship between  them  and  thus  are  asynchronous.  Often,  however, 
the  occurrence  of  some  programmed  action  within  a computational 
process  is  of  interest  to  some  other  computational  process.  The 
occurrence  of  this  programmed  action  then  is  considered  an  even t . 
Since  its  time  of  occurrence  is,  in  general,  undefined  outside  the 
process  which  caused  it,  in  general  it  is  also  asynchronous.  At 
times  it  is  required  to  maintain  some  predefined  sequential  re- 
lationship between  programmed  actions  in  otherwise  asynchronous 
parallel  computational  processes.  This  is  called  the  s vn c h ro n i za t i o n 
of  parallel  processes. 

In  a computer  system  it  is  also  possible  to  have  an  occurrence 
which  is  not  a programmed  action  within  any  computational  process, 
and  which  requires  some  response  from  the  system.  Such  an  occur- 
rence is  called  an  interrupt . 
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The  general  organization  of  the  systems  upon  which  this 
language  is  to  be  used  is  assumed  to  include  software  responsible 
for  operating  the  computer  system,  often  called  the  executive  or 
operating  system,  and  the  application  software  which  will  be  run 
as  (possibly  parallel)  computational  processes. 

Direct  interrupt  handling  is  considered  to  be  within  the 
province  of  the  operating  system,  and  any  language  proposed  for 
interrupts  will  not  be  used  in  applications  programs.  The  event 
language  will  be  used  to  provide  real-time  operation  of  applications 
programs  through  an  event  supervisor  in  the  executive. 

FUNCTIONAL  REQUIREMENTS 

A user  of  a procedural  language  for  the  real-time  program- 
ming of  industrial  computers  must  have  the  following  capabilities: 

Interrupts 

• Ability  to  indicate  that  some  segment  is  to  be  executed 
upon  the  occurrence  of  some  particular  interrupt. 


Events 


■ Ability  to  retain  the  flow  of  control  at  a point  in  a 
computational  process  until  some  event  has  occurred. 

• Ability  to  cause  the  occurrence  of  an  event  at  some  point 
in  a computational  process. 

Synchronization 

• Ability  to  synchronize  parallel  computational  processes 
with  security. 
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TASKING  FACILITIES 


INTRODUCTION 


The  purpose  of  this  section  is  to  propose  a set  of  functional  re- 
quirements for  the  tasking  facilities  of  the  LTPL.  First  a 
number  of  terms  are  defined  (in  the  Appendix).  These  terms  are 
used  to  describe  a very  general  model  of  tasking.  The  next  section 
proposes  a set  of  functional  requirements  for  the  LTPL  in  terms 
of  this  general  model.  This  proposal  combines  the  valuable  features 
of  all  the  previous  proposals  on  the  subject  into  one  unified 
facility.  The  last  section  very  briefly  discusses  the  relation  of 
these  proposals  to  existing  or  proposed  languages. 

MODEL 


This  section  is  an  attempt  to  define  a model  for  the  operation  of 
a task  and  the  interaction  between  tasks.  Thic  model  is  intended 
to  be  rich  enough  to  include  all  the  functions  available  in  many 
existing  and  proposed  systems,  although  most  systems  do  not  contain 
all  the  functions  available  in  the  model.  Later  in  this  paper  an 
attempt  will  be  made  to  reduce  the  model  to  a more  compact  form 
that  satisfies  the  functional  requirements  for  a procedural  language 
for  industrial  computer  applications. 

A task  can  be  in  one  of  a number  of  states.  In  some  states  addition- 
al information  is  required,  such  as  the  segment  which  the  task  is 
executing.  The  state  of  the  task  and  the  additional  information 
required  for  particular  states  is  contained  in  a portion  of  storage 
called  the  state  vector  of  the  task.  This  state  vector  is  known 
to  the  system  and  is  used  by  the  system  to  control  the  execution  of 
the  task. 

Figure  1 illustrates  the  possible  states  and  some  of  the  transitions 
that  could  take  place  between  them.  In  principle,  a transition  is 
possible  from  any  state  to  any  other  state,  but  some  oJ  these  trans- 
itions are  of  little  practical  v,i  ! i-  . The  meanings  oi  the  variou: 
states  are  as  follows: 

0 . N on exi_s ten i _t 

The  task  is  not  known  to  the  system  in  arm  way;  i.e.,  no 
storage  has  been  allocat  d to  contain  the  state  vector  for 
the  task.  (Since  the  t 1 k does  r.ot  exist,  this  is  not 
really  a "state",  but  cor.  i ’ s'i  it  i such  clarifies  the 
discussion)  . 
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1 . Do  rma  h t 

The  task  is  known  to  the  system;  i.e.,  storage  for  its 
state  vector  has  been  allocated.  However,  no  segment 
or  data  area  is  associated  with  the  task  in  this  state. 

2.  Idle 

The  task  exists  and  has  a segment  and  a data  area  associ- 
ated with  it.  However,  execution  of  the  task  is  neither 
taking  place  or  scheduled  to  take  place. 

3 . Runable 

The  task  is  ready  to  execute  and  has  all  requested  re- 
sources allocated  to  it  except  for  a physical  processor 
to  execute  its  code. 

4 . Suspended 

The  task  is  waiting  for  some  event  to  occur,  such  as  for  a 
resource  to  become  available  or  for  some  other  task  to  give 
it  a signal  to  continue. 

5 . Schedul  ed 

Execution  of  the  segment  associated  with  the  task  is  sched- 
uled to  occur  at  some  future  time  or  on  the  occurrence  of 
some  event.  When  the  time  is  reached  or  the  event  occur  s , 
the  task  is  automatically  transferred  to  the  runable  state. 

The  main  difference  between  scheduled  and  suspended  is  that 
the  scheduled  state  exists  before  execution  of  the  segment 
has  started,  whereas  the  suspended  state  occurs  in  the  midst 
of  execution  of  the  segment. 

6 . Running 

A physical  processor  is  actually  executing  the  segment 
a s soc i a t eel  with  the  ta s k . 

A task  exists  if  it  is  in  any  state  except  state  0.  A ta  d<  is  said 
to  be  act ive  if  it  is  in  any  of  the  states  ? throe. h 6,  i.e.,  it  it 
has  a segment  and  a data  area  assigned  to  it.  A task  is  ext  cut  in; 
if  it  is  in  states  3,  4 or  6.  Thus,  a process  can  be  described  .s 
all  the  actions  that  a task  performs  during  the  time  period  hetwren 
a particular  entrance  to  the  executing  stale  and  the  next  exit  1 ro 
the  executing  state. 
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The  transition  from  one  state  to  another  can  be  caused  by  an  actic 
of  the  task  itself  or  by  an  action  of  another  task  or  by  some  action 
of  the  system.  In  order  to  clarify  the  meaning  of  the  state 
diagram,  it  will  be  helpful  to  explain  the  actions  required  to 
cause  some  of  the  more  important  transitions. 

A task  comes  into  existence  when  a state  vector  for  it  is  allo- 
cated and  this  state  vector  is  made  known  to  the  system;  it  ceases 
to  exist  when  the  state  vector  is  de-al  located  or  when  the  syster. 
ceases  to  be  aware  of  the  state  vector.  A task  becomes  active 
when  a segment  and  a data  area  are  assigned  to  it,  and  inactive 
when  the  segment  and  data  area  are  released.  A task  moves  from 
the  idle  state  to  the  scheduled  state  when  the  system  is  informed 
that  the  task  should  be  executed  at  a particular  time  or  on  the 
occurrence  of  some  event.  The  task  starts  executing  when  a sched- 
uling condition  is  met  or  when  another  task  requests  its  oxen: t 

The  reason  for  having  both  the  idle  and  the  dormant  states  is  to 
allow  for  a distinction  between  the  creation  of  a tasking  <r.u  assign- 
ing a code  segment  to  it.  In  some  languages  both  of  these  functions 
are  performed  by  the  declaration  of  a task,  i.e.  the  declaration 
puts  the  task  into  the  idle  state.  In  other  languages  the  se  . ent 
nay  not  be  specified  until  the  task  is  put  into  either  the  runable 
or  the  scheduled  state,  and  therefore  the  declaration  puts  the  tas 
in  the  dormant  state. 

A task  starts  executing  by  entering  the  runable  state.  Transitions 
between  states  3 and  6 are  caused  automatically  by  the  system  ind 
are  not  under  the  direct  control  of  any  task.  At  any  instant  in 
time,  any  number  of  tasks  can  be  runable,  but  the  number  of  ruin  : r 
tasks  is  limited  to  no  more  than  Lite  number  of  physical  processor- 
available  to  the  system.  The  mechanism  by  which  the  system  decide 
which  task  should  be  run  by  a given  physical  processor  at  a partic- 
ular time  involves  a numerical  value  which  is  part  of  the  st  te 
vector  and  is  called  the  priori ty  of  the  task.  When  a ph\  m >i 
processor  becomes  available,  the  system  allocates  it  to  the  hi  su 
priority  runable  task.  If  several  runable  tasks  have  the  same 
priority,  the  system  makes  an  arbitrary  choice.  Some  systems  may 
only  have  one  priority  level,  hut  this  is  generally  not  useful  in 
an  industrial  computer  application. 

If  a task  wi  t.iier.  to  change  it  ; own  state  vector,  it  does  so  by 
making  a request  to  the  system  While  this  request  is  being  pro- 
cessed, the  task  is  still  considered  to  be  in  the  running  state. 
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Therefore,  the  only  transition  which  a task  can  cause  on  itself 
are  the  transitions  from  state  6 to  one  of  the  other  states.  A 1 
other  transitions  can  he  caused  only  by  the  actions  of  other  t •* 
or  of  the  system.  In  principle,  a task  can  request  a transition 
of  itself  from  state  6 to  any  other  state,  and  can  request  an.' 
possible  transition  for  another  task.  In  a practical  system,  how- 
ever, only  some  of  these  possibilities  will  be  allowed. 

One  of  the  more  important  states  in  ;he  model  is  the  suspended 
state,  state  4.  Where  a task  is  suspended,  it  is  not  perfon  ins 
any  actions  but  is  waiting  for  something  to  happen  outside  it -elf. 
When  the  awaited  thing  happens,  the  task  becomes  runable  again. 
While  a task  is  suspended,  it  can  be  waiting  for  one  of  the  follow- 
ing things: 


1.  A time  interval  to  elapse. 

2.  Another  task  which  requested  its  suspension  to  allow  it 
to  continue. 

3.  An  event  to  occur. 

4.  A semaphore  which  it  is  trying  to  secure  to  be  released 
by  another  task. 

5.  \ resource  controlled  by  the  system  to  become  available. 

Some  systems  may  allow  a task  to  be  waiting  for  more  than  one  thin 
at  the  awe  time.  If  this  is  allowed,  there  must  be  a set  of  rules 
to  determine  what  combination  is  required  to  make  the  task  runable 

Although  this  paper  is  not  intended  to  deal  with  interrupts,  a 
brief  discussion  of  the  relationship  of  interrupts  to  this  model 
is  appropriate.  There  is  no  mechanism  for  an  interrupt  to  affect 
the  state  of  a task  directly.  However,  recall  that  a task  can 
enter  the  runable  state  from  either  the  scheduled  state  or  the 
suspended  state  on  the  occurrence  of  an  event.  It  is  possible  for 
a system  to  provide  a facility  for  establishing  a connection  be- 
tween an  interrupt  and  an  event.  Once  this  connection  is  establi;  - 
ed,  the  system  will  automatically  cause  the  event  to  occur  when 
the  interrupt  is  received.  A facility  for  establishing  and  control 
ling  inch  connections  should  be  provided  by  an  industrial  computer 
syst cm . 

To  summarize,  then,  a task  is  defined  by  a state  vector  which  con- 
sists of  the  following  components  (some  of  which  may  be  empt  y at 
va  r i ous  t imes ) : 
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1.  A state  number. 

2.  The  name  of  a segment. 

3.  The  name  of  a data  area. 

4.  A priority  number. 

3.  A list  of  scheduling  conditions. 

6.  A list  of  things  for  which  it  is  waiting. 

Three  things  can  change  the  value  of  the  state  vector:  the  task 

itsell,  another  task,  or  the  system. 

I TNC'l  10k  U,  RF.OUI  RKML'NTS 

Once  the  model  of  a task  has  been  defined,  it  is  possible  to  pro- 
ceed to  consideration  of  a language  that  will  provide  those  parts 
of  the  general  model  which  are  required  for  industrial  computer 
applications.  This  must  be  done  in  two  stages:  first,  select 

those  parts  of  the  model  that  are  required  by  the  application, 
i.e.,  define  the  functional  requirements;  second,  define  language 
features  that  will  satisfy  these  requirements.  This  paper  wiil 
only  attempt  the  first  of  these  two  steps.  This  section  will 
propose  a subset  of  the  general  tasking  model  as  the  functional 
requirements  for  a procedural  language.  These  functional  require- 
ments ii, list  he  co:  i tiered  by  the  LTPL  Committee,  and  only  when 

agreement  on  the.,  is  reached,  we  can  proceed  to  defining  the 
language  features. 

The  specific  functional  requirements  proposed  bore  have  been  dis- 
tilled lr*om  all  the  previous  work  done  by  the  participants  in 
LTPLC  from  throughout  the  world. 

In  terms  of  the  tasking  model  presented  above,  all  that  is  needed 
to  specify  the  functional  requirements  for  a particular  applies!  ion 
is  to  specify  which  state  transitions  are  allowed  and  what  informa- 
tion must  be  supplied  when  one  of  the  transitions  is  requested. 

The  transitions  which  can  he  caused  by  a task  for  itself,  for 
another  taslc,  and  by  the  system  must  be  separately  specified. 

The  following  paragraphs  define  the  functions  required  in  each  of 
the  three  areas.  Each  function  is  given  a name  written  in  lev  cr- 
ease and  underlined.  These  names  serve  onl y as  labels  for  function- 
al capabilities  arc  are  not  intended  to  have  any  relation  to  possible 
I ingu i st i c representat ions . 

A task  is  made  known  to  the  system  with  a declaration,  which  assigns 
a name  Lo  the  task  and  causes  a state  vector  for  it  to  be  stat  ic- 
al  1 v 1 1 located.  Tin’s  doc:  not  actual  1 y cause  t lie  task  to  exist; 

the  task  is  bronchi  into  existence  when  the  system  perforins  the 
crcil  < fund  ion.  Tin’s  occurs  when  the  block  coni  ai  ning  the  declar  - 


L 


tion  is  activated;  i.e.,  when  the  static  declaration  is  invoke!. 
The  create  function  puts  the  task  in  the  dormant  state.  The  syst< 
can  return  the  task  to  the  nonexistent  state  when  it  performs  the 
d e 1 e t o function.  This  occurs  when  the  static  declaration  ceases 
to  exist;  i.e.,  when  the  block  containing  the  declaration  is  de- 
activated This  task  can  be  made  available  to  other  blocks  by 

i ' ing  LtJ  name  available  through  th<  normal  lai  ua  rules  fc 
scope  of  names  or  by  passing  it  as  an  argument  to  a procedure. 

0 ce  a task  exists  it  can  be  ictivated  by  anothei  tas!  with  <•  i 
the  execute  or  the  schedule  function.  In  either  case,  a sc  ••  rut 
name  must  be  supplied.  The  data  are.  pplied  lutor.atic  : 1 

by  the  system  through  activation  of  the  outermost  blocs  of  th 
segment.  In  the  case  of  the  execute  request,  the  task  enters  the 
T unable  state.  The  scliedul  o request  puts  the  L .sk  in  the  sched.ulo. 
state  and  requires  that  scheduling  conditions  be  suppli  f. . 'these 
conditions  can  consist  of  an  initial  time,  a c , tit ion  Inter  1 1 , 

and/or  an  event.  When  the  scheduling  condition  are  net,  il.i 
systu  a makes  the  task  runablc  with  the  n-tuh  action.  Hither  the 
cy.nciUo  or  the  schedule*  request  may  optionally  spec  it  an  eve  t 
which  is  to  occur  when  the  task  stops  executing. 

One  task  can  suspend  another  with  either  a delay  or  a sr>  * 
request . Th.  d<  ■ tv  func tion  must  ; ; a tinu  peril 

j ec L task  wi  11  b suspem  *d  for  that  pi  i od , fti  Lcl  it  to 

matically  become  rt  ible  agai  , I end  i t . : 1 1 b 

the  object  task  suspended  until  some  task  m ikes  it  run  shit*  a.  in 
with  a conj  in  nr  request  . 

A task  can  stop  the  execution  of  another  task  \ •’  t i*  tho  ter  t 
function.  1 the  c j ec  t t < i ! ! ■ i 

it-  state  vector,  it.  wi  ] 1 enter  the  scheduled  tale;  othervb  n 
i 1 will  becomi  don  nt , Tin  < I Lon  v;i  11  prod  t 

results  except  it  applies;  to  Hr  t » ! bat  c\ecn'  >•  it  itself. 

The  system  car  also  stop  the  . eciit  ion  of  .•  task  with  the  s.i: ..  re 

suits  by  performing  the  abort  action. 

A task  can  make  another  task  dor  u 1 regardlc'S  of  any  schodui  5np. 
conditions  hv  using  the  k • 11  turn  ! i mi.  Air  cl*  :•  out  any  sched- 
uling conditions  v;hich  \ ■ y hay  . ••  ‘ ted.  .lie  s.  :.i  . v.  can  c > ih  i 
w i th  the  cuter mi nat  act i . . . ■ < . < • econu. 

dormant  with  the  K_i  1 ] me  reque  •'  . 

Once  a task  is  runablc,  the  s;  l wm  pv.t  it  : .i  tin  running  let. 

with  the  run  action.  The  a:v-  . pi  . ti  i . I f.  s\  stem  l*c I urns  t i . > 
t a H<  to  the  runabli  .state. 
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A task  can  suspend  i is elf  with  either  the  delay)  • or  the  wait 
function,  which  must  specify  either  a time  interval  or  on  event, 
respectively.  A task  can  also  be  suspended  if  it  execute:  the 

secure  function  on  a semaphore  that  has  already  been  secured.  In 
this  case,  it  will  become  runable  again  when  another  t isk  executes 
a release  on  the  same  semaphore. 

If  a task  requires  t he  use  of  a resource  which  is  controlled  auto- 
matically by  the  system  and  that  resource  is  unavailable,  the 
S>  tem  will  suspend  the  task  with  the  inhibit  action.  The  system 
can  make  a suspended  task  ru liable  with  the  un.ni  ; nd  function, 

which  will  happen  if  the  task  was  waitin;  for  a tine  interval,  an 

event,  or  a system  m source  and  the  awaited  condition  becomes  true. 
Tf  the  task  is  vvi  i t'i  ng  for  an  event,  another  task  can  make  it  run- 
able  with  the  s_i  sa  ks_L  function  specifying  that  event. 

There  are  also  several  functions  that  do  not  directly  change  the 
state  of  a t ask,  but  do  af  fect  the  other  in  forma t i on  in  the  st  ..re 

vector . A sc hedul erne  request  ’..ill  put  a scheduling  con  i.Li<  iLs 

the  state  vector  The  priority  of  another  task  can  be  see  w i t h 
priority,  in d of  the  requesting  task  with  myprioritv.  Similarly, 
the  entire  state  vector  of  a task  can  be  examine  d with  either  s t i to, 
(for  another  task)  o>  invj-frfus  (for  the-  same  task). 

Tab] « 1 sum  sir  i z».  . ..11  tho  functional  capabilities  required  for 

tasking,  'ibis  tabl  nu  ;.l>crs  each  function,  shows  the  off  i cl  r.i  the 
state  vector,  and  specifies  l he  i nf  orr.  tion  that,  must  he  r.uppl  i ed 
for  each . Foi  all  the  functions  that  require  a task  is  an  arj  • nt , 
an  error  occurs  if  that  task  is  not  in  the  sf  a re  specific.1  on  •:  he 
J ci  t- 1 land  side  in  the  state  change  coin;:;:  - . figure  2 show . a>l  the 
o>  th<  ; L a t < 1 i a gr a . v.  i f h < h ti  i J tion  labeled  \ t 
the  appropriate  function  numbers  from  Table  1. 

Although  the  list  of  function:'!  capabilities  looks  very  et  plicate 
at  first,  i i is  much  simple  r than  the  complete  ■ 1 . Not  e t it 

state  7 is  licit  used  at  all,  and  only  about  half  the  possible  t •*  n 
i i i oi ; . a re  u ed . Also , analo  ou  oj  i i i.o  n defined  r 
functions  depending  on  whether  they  open  at<  on  the  ciu  rent  tr.d  or 
anothcr  task  . However , these  pairs  of  fund. .ions  could  each  be 
implemented  with  a single  language  fe.itur.  . Foi  i re  l .race , a i ng]  < 
1)R  I AY  j-  to  tc-ment  could  lie  used  without  a i.-wk  no  . for  del  me  mb 
wj  tli  a task  name  for  delaj^ . Similarly,  II  the  sys  tei  wer<  i j I . t 

ed  in  the  same  language,  some  of  tho  s.yst  em  fund  Lons  could  b« 
impler.iciited  with  Hie  same  law  u.gr.o  features  as  i • .i  c of  Liu-  non*  syde 
turn. l ions.  Furt  . .ermore , although  . lot  el  funeti ons  have  been  dc 
f ined,  each  one  repr  . . i ; t s a I il.rly  s impl*  opera t ion  on  tin  si  t < 
vector;  there1 or  they  should  not  be  vor * difficult  t o imp  It 


lit  . 


Since  the  idle  state  in  Figure  2 has  no  transitions  enterin'  it 
or  leaving  it,  it  appears  to  be  unnecessary.  However,  it  is  use- 
ful to  retain  this  state  in  the  mode]  so  that  the  model  is  st:ll 
powerful  enough  to  show  the  features  of  all  the  proposed  language' 
mcl  so  that  it  will  be  still  pos:  i b I e to  consider  prop  . ■ I . to 
add  functional  requirements  that  require  the  use  of  the  idle  state . 


FUNCTIONAL 
OP 'VAT  I ON 


ST  ATT  CIIANGF. 

|!  OF  O'  1 L C T TASK 


; APr,uni:NT  rcircu  ; 


C ! 'Ml  G 
(if’  ; I ' ( r> 

<! ! ; O ? ' 

« x t:<  . 1 1 i rr  1 1 

}'}  ■ ■ M.ty 
i.  i n 

p'  f- 

i r ' i ■ I it 
un  u:  : ■ i 
lull  J.1C 

-iuriP1 
*r.y:; * '■  fcus 


y •!  : :r.  i 

i ■ ' ‘ . ’ I K » t . ( 

TV;  i 


.M't'.li 
pr  I O'  i ty 

V,  T.S 


P ' 1 

1 V 

3 ,4/01  C.  -]  or  S 
r .or  6-0 
!>  • 3 
3 >6 
r ? 

r>  •>  -i 

add;,  to 
I kcIjcm  ' u ) c ] .i  r<  t 
I'l.otr;  priority 
••  rotl:  !•?,:;  state 
j:  vector 

C 1 J O r 5 

G->  J 


j < t a;-.);  > 

i < ta f. ■ 

I < La s); > 
<ta  :■;!;> 

i <!<•■••):•••  ' 

; <t 

j!  < tas).  > 

I:  < Lar-k> 

< ta  ‘.;k> 


< MO  s I < GVOii ' > 

, <prior.ity  1 rv  ! 


i vc-c  : 


'■  <tir.(  ' 

i ^ 

or  C, 

' vl-'  ■ ■ - ■■ 

•3 

It 

< t ; 

;■) 

| i ■'  , { i 

G >4 

< tat;  5 

C v 4 

1'  tar ■ , <{  i];ie> 

3 

I! 

6 ’3  or  S 

< ta  ■ ' 

i >1 

ij  < t a ' k > 

3 

£ " pci.iaj  J)  iro> 

3 

i <ovent> 

• io  r i 1 y 

! VVer 

staio 

j1  <ta 

< >j: 

■F  * .A  . i. 


FIGURE  2 


STATE  DIAGRAM  OF 
PROPOSED  TASKING  SYSTEM 
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> Lh  . :s  . : V..  ■ 


All  aota  can  eo  min  a . 

Th  : only  implicit  Jot;  ‘ ■ conversion  ccurs  3uri 

assignment  or  with  1/0  ■ perations . 

Problem  data  most  include  arithmetic  and  string  data . 

Program  < < ltrol  data  must  include  data  types  r«  }uired 
support  tasking,  events,  interrupts,  1/0,  synchroni.iat i n 
and  flov;  of  centre!. 

Ha rdwn re/Soft ware  data  types  for  interfacing  hardware  and 
software  should  be  provided  as  required. 

Arithmetic  data  will  include  integer  and  float  d ta  t a 

String  data  must  include  charact<  r strii  ;s  and  1 11 
There  will  be  both  fixed  and  vary in  ; . t rings  . 
string  length  is  implementati  n dependent. 

Data  are  organised  as 

a.  Scalar  Data  (single  items) 

b.  Data  Aggregates 

. Arrays  (wherein  ail  elements  of  the  array  are  cf 
the  same  typo) 

. Structures  (all  elements  d not  have  to  b<  th< 
type) . 

There  shall  be  a mechanism  fir  accessing  any  particular 
e ■ n f a data  ; ^gregate. 


V ere  sh  ill  l fa  ■ : 5tie;  for  manipulatios  f j )r  ! • . 

1 r a ..  c ntr  . . 3 ’d  ware/s  of  twar<  inkage  dal  . 

Operators  will  include 


+ - prei ix 
+ - infix 

* / 

-** 

and,  or  not 
■ a ar  L:  . .a 
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4. 

STATIC  PROGRAM  STRUCTURE 


INTRODUCT  TON 

Necessary  to  any  procedural  language  is  a means  of  specify- 
ing the  structure  of  the  program.  This  paper  addresses  static 
program.  These  are  the  facilities  needed  to  define  a collection 
of  statements  to  be  a program,  specify  data  and  data  structures 
and  manipulation  of  that  data. 

DEFINITION 


In  discussing  data  types,  problem  data  means  data  items  such 
as  fixed-point  variables.  Program-control  data  is  utilized  by 
the  tasking  and  interrupt  handling  facilities. 

F UNCT I ONAL  REQU I RENENTS 

A programming  language  for  real  time  industrial  computers 
must  provide  the  following  capabilities. 

DEFINING  A MODULE 


• Means  to  identify  a group  of  statements  to  be  treated  as  i 
module.  (Such  as  an  in-line  function  or  a subroutine). 

• Means  to  identify  a module  or  group  of  modules  as  a segment 
A segment  would  be  available  for  tasking  and  interrupt 
handling  purposes. 

SPECIFYING  DATA  TYPES 


The  ability  to  declare  names  and  attributes  of  problem  d.at 
program-control  data  and  hardware/software  linkage  data. 

Explicit  declaration  shall  be  required  where  standard  de- 
faults or  contextural  declaration  cannot  supply  reason  M>i<  . 
understandable  attributes. 


1 
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STATEMENTS 


statements  which  provide: 

• Ability  to  assign  values  to  data  items. 

• Ability  to  specify  operations  to  be  performed 
with  data  items. 

• Ability  to  call  a subroutine. 

• Ability  to  invoke  an  in-line  function. 

• Ability  to  specify  several  statements  as  a group 
for  looping  or  iterative  operations. 

• Conditional  and  unconditional  branching  for  alter- 
ing the  flow  of  control  within  a program. 

MODULARITY 


The  language  shall  facilitate  the  linkage  of  separately 
compiled  modules. 

The  language  must  provide  the  ability  to  specify  the 
scope  of  data-items  within  and  outside  of  the  modules. 


L 


-78- 


5)  i/o  KEr'UiFtF.'-'Eirrs 


In  a programming  language  for  realtime  applications  it  is 
necessary  to  hove  available: 


A sufficiently  nowerful  set  of  I/O  statements  and  fcrmattin 
possibilities  for  input  and  utput  cf  numeric  and  alpha- 
numeric data  which  is  not  too  complex  and  complicated 
to  be  efficiently  implemented. 


2.  A possibility  to  transfer  unformatted  data  e.  g.  to  and 
from  backing  store  or  between  computers  in  a computer 
network. 

3.  Tools  for  particularity  process -oriented  data  transfer 
with  special  emphasis  on: 

3.  1.  efficient  use  of  process  control  hardware 

3.  2.  the  possibility  for  the  programmer  to  add  new  4 ye  or 
of  I/O  - facilities  for  new  and  non-stai  3 rd  ; 
devices 

3.  3.  Inter-system  transfers  which  do  n t touch  the  CIV 
or  even  the  main  computer 

3.  4.  the  ability  to  efficiently  program  I/O  which 

involves  a data  transformation  related  t the  l.1' 
operation  (e.g.  conversi  -n  from  analog  coui  ts 
engineering  units) 


4. 


I/O  shall  be  defined  in  a way  that  facilitates  the  e n- 
;tr  icti  t f ew  hi  : ler  level  E A - functis  i s fr<  i t < 
b-:.  j c ■ es  (e.g.  ippropriate  yr  :hr  * i : r necl  onisi 

should  allow  the  executive  of  an  output  and  the  respect 
input  re cp  tare  in  one  Lr  visible  operation). 


i ve 


Ihe  anguage  with  f itate  graphics  I/O. 


6.  The  lan; mage  should  facilitate  efficient  file  handling. 

The  user  shall  be  cable  to  define  error  recovery  f r I/O 
operatic  ns . 


7. 
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8.  The  definition  of  I/O  must  not  lead  to  an  implementa- 
tion which  conflicts  with  the  tasking  structure  of 
the  user  program. 


-80- 


6. 


DYNAMIC  PROGRAM  STRUCTURE 


Functional  Requirements 


1.  The  language  shall  support  multiple  and  nested  re-entrancv 
upon  user  declaration. 

2.  The  language  need  not  support  recursion. 

3.  The  language  shall  automatically  support  allocation  of 
storage  for  modules  declared  re-entrant. 

4.  There  shall  be  explicit  means  to  dynamically  allocate 
storage . 

5.  It  shall  be  possible  to  activate  a task  whose  continued 
activation  is  not  dependent  upon  the  continued  existence 
of  its  activator. 

b.  The  language  shall  have  facilities  for  transmitting  data 
from  one  task  to  another. 

7.  The  language  shall  have  facilities  for  sharing  data  between 
tasks . 
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PROGRAM  MANAGEMENT  FUNCTIONAL  REQUIREMENTS 
Features  for  software  visibility 

Contents  of  programs  should  be  visible  through  various 
tools  such  as  listings  and  messages  during  program  pre- 
paration, debugging,  and  maintenance.  Features  of  docu- 
mentation useful  for  this  purpose  are  as  follows: 

(1)  Source  program  listing 

(2)  Intermediate  language  listing 

(3)  External  references 

a)  Routine  entry  names 

b)  Data  names  referred  from  external  programs 

c)  External  routine  names 

d)  External  data  names 

e)  Common  data  names 

(4)  Symbol  table 

(5)  Physical  memory  map 

(6)  Program  unit  name  listing 

(7)  Program  structure  listing  (phases,  local  subroutines, 
etc . ) 

Compile  time  facilities 

It  is  desirable  for  the  language  to  have  some  compile 
time  facilities  which  contribute  to  the  flexibility  of 
language  through  conditional  compilation.  These  facilities 
should  be,  however,  investigated  carefully  because  they 
will  introduce  a pre-compilation  phase  to  the  compiler 
and  it  may  be  too  much  for  small  size  computers. 


V 


1 
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3.  The  language  design  shall  give  careful  attention  to  the 
provision  of  debugging  features  such  as: 

Setting  of  conditions  for  debugging  operations 
Executable  statements  for  debugging  operations 
Auxiliary  listings  useful  for  debugging 
Error  messages 
etc . 
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8. 

Hardware  - Software  - Linkage 


Functional  Requi  rcm.onts 

1 . Ability  to  inf  on.:  the  system  through  a mechanism,  such  a i 
a symbol  table  available  to  the  compiler,  of: 

a)  The  physical  termination  identification  of  each 

peripheral  industrial  application  component 
(process  I/O  device)  with  which  it  mu:t  communi- 
cate: (sample  specification  statement) 

Program  Identifier  - Physical  Terminal  ion  I dent  i i i er  (!!>') 

b)  The  physical  identity  of  the  comrnuni  cation  channel  ( • 

over  which  information  wil  l be  exchanged  \:i  th  each 
industrial  applications  c i pon  i t:  (s  < L< 

t i on  statements) 

Program  Identifier  = (industrial  appl:c..ion  tv  ponent) 
vi'  (co  anun  i cat  ion  ch  nnel,  idci  uifier)  Dit  to  rot 
...  ; I ipplication  con  pon<  :nt)  via  (<  tv  on 

channel . identifier) 


c) 

The 

physical  idert 

i f i c a t i en  o f : 

1. 

each  separable 
ident i f ier 

interrupt  level 

and 

i ts 

progr  im 

2. 

each  separable 

in' o erupt  point 

a t a 

g : 

ven  level 

and  it;,  progr 

in  identifier 

The 

reque 

st or  can  speci 

fv  an  1 /O  device 

in  a 

S y 

nbolic  wav. 

1 L : 

shoe  1 d 

not  be  necess 

ary  for  the  rvque 

s l o r 

to 

know  a devie 

!nu  i.ber  and  other  hardware  character]  sties  peculiar  to  a 

device,  such  a;  channel,  li.no  and  eqr  : pment  numbers. 


The  language  must  facilitate  the  ability  to  s. itch  devices 
in  a secure  way  in  case  of  failure. 
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cal  ■ ; e pr  ; rr  t 
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SECTION  III 


REQUIREMENTS 

COMPUTERIZED 

SEQUENCING 


FOR  DATA  COLLECTION, 
SYSTEM  CHECK-OUT  AND 
CONTROL  FUNCTIONS 


One  of  the  topics  discussed  at  length  at  the  First  and 
Organizational  Meeting  of  the  Purdue  Workshop  on  Standardiza- 
tion of  Industrial  Computer  Languages  was  that  listed  above. 
The  group  at  that  time  produced  the  attached  document  which 
was  published  as  pp . 59-66  of  the  Minutes  of  that  First 
Workshop . 
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REQUIREMENTS  FOR  DATA  COLLECTION, 

COMPUTER  I /EE)  SYSTEM  CHECK-OUT  AND  SE  IJENCIii  : 

CONTROL  FUNCTIONS 

I.  SYSTEM  ERROR  CHECKING 

In  the  process  of  implementing  a high-level  language  to 
free  the  engineer  from  the  details  of  machine  and  assembly 
language  programming,  we  are  also  removing  a portion  of  the 
skill  presently  used  to  implement  and  maintain  computer  syo  • . . 

To  replace  these  skills,  diagnostic  procedures  to  isolate  • u. 
analyze  system  failures,  both  equipment  and  programming,  must 
be  implemented  with  the  language.  Under  these  procedures, 
system  errors  should  be  reported  to  the  engineer  in  his 
language;  communicating  the  nature  of  the  error,  where  it 
has  occurred,  and  specific  information  to  aid  in  the  diagnosis 
and  correction  of  the  error. 

Further  to  the  definition  of  an  error,  recovery  proc^du*'  ■ 
are  necessary  to  maintain  the  integrity  of  the  system  to  the 
fullest  possible  extent.  These  would  typically  Include  hi  • 
provisions  to  transfer  the  function  (in  error)  to  an  alterne. 

(if  available),  temporarily  delete  the  function  from  -the; 
system,  or  any  similar  actions  possible  to  allow  the  remainder 
of  the  system  to  continue  operating. 


k 
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TT.  REQUIREMENTS  FOR  I' AT  A COLLECTION  - ANALOG  TNFUTf 

1.  Conversion  to  Engineering  Units 

A.  User  will  have  the  ability  to  specify  conversion 
equations  beyond  those  provided  with  the  system. 

R.  User  will  have  the  ability  to  change  any  of  th<  para- 
meters in  the  conversion  equation  on-line. 

B.  The  data  can  be  made  available  to  the  user  in  either 

fixed  or  floating  point  format  on  a system  basis. 

D . The  data  can  be  made  available  to  the  user  in 

engineering  units. 

2.  Timing 

A.  User  will  have  the  ability  to  do  either  continuous 
scanning,  random  scanning  or  both  continuous  and  raudc 
scanning. 

B.  User  will  have  the  ability  to  define  a sequential 
relationship  between  the  variables  being  scanned. 

C.  User  will  have  the  ability  to  specify  the  scan  f r - 
quency  on  a point  basis. 

D.  User  will  have  the  ability  to  add  or  delete  point  e 
on-line. 

Pi gi tal  Filtering 

A.  Digital  filtering  will  be  optional  on  a point  b?  sis. 
User  will  hav  > tl 1 a ab ility  to  sp  ?c 3 fy  filteri  fut 
tions  beyond  those  provided  by  the  vendor. 

User  will  have  the  ability  to  change  all  paran  * rs 
on- I ine. 


— 


Limit  Checking 

A.  The  user  will  have  the  abiiity  to  specify  either  on 
or  two  sets  of  alarm  limits  on  a system  basis. 

B.  A dead  band  will  be  provided  at  the  alarm  limits 
and  the  size  of  the  deadband  can  be  specified  on  ■ 
point  basis. 

C.  A significant  change  test  will  be  provided  and  the 
size  of  the  change  can  be  specified  on  a point  bar ' 

1).  The  user  will  have  the  ability  to  change  any  of  ■ 
parameters  on-line. 

E.  The  user  will  have  the  ability  to  determine  th  lir. 
checking  frequency  on  a point  basis. 

F.  A linkage  will  be  provided  to  other  system  programs 
on  limit  violations. 

Scanning 

A.  The  ability  will  be  available  to  read  a point  by 
providing  the  necessary  point  identification  param 
and  other  applicable  scanner  hardware  parameter.'. 

B.  A linkage  will  be  provided  to  other  system  pr.  i 

when  scanner  errors  are  detected. 
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ITT.  REQUIREMENTS  FOR  A GEQUENCTNH  LANGUAOF, 

I'1  lie  Structure  - Due  to  the  many  programs  or  recipes  and 
associated  data  necessary  in  batch  processing,  extra  effort 
should  be  applied  to  the  development  of  an  efficient 
file  structure. 

Logical  and  Relational  Functions  - Due  to  the  many  on-  T 
tasks  associated  with  sequence  control  or  batch  procr  ss'n 
efficient  and  useable  logical  and  relational  functions 
are  necessary. 

T i using  - The  sequence  programs  used  in  many  manufacturin', 
processes  require  a rapid  response  including  both  recog- 
nition and  action,  to  either  cyclic  scan  programs  or 
p rocess  i nterrupts . 

Lfseabl  ] 1 ty  - It  is  quite  important,  especially  for  batch 
processing  type  applications,  that  the  process  engineer 
be  able  to  accomplish  the  programming.  it  is  his  process, 
knowledge,  especially  his  knowledge  of  what  can  go  wtvng 
and  what  to  do  about  it,  which  is  being  transferred  inti 
the  computer  system.  In  cases  where  it  is  necessary  for 
computer  oriented  engineers  to  develop  the  programs.  It 
is  still  necessary  for  the  process  engineer  to  review 
those  programs  in  detail.  Therefore,  a self  explanatory 


system  is  quite  important. 
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A.  The  Application  Engineer  should  definitely  not  have 
to  concern  himself  with  bits  or  byte  handling,  the 
real  time  operating  system,  interrupt  responses,  or 
routine  I/O.  The  sequencing  language  should  automa- 
tically make  use  of  these  to  carry  out  its  funeti;  ns. 
P.  As  much  as  possible,  the  Application  Engineer  should 
be  able  to  use  ordinary  English  to  define  his  quip- 
ment  and  write  his  programs. 

C.  The  Language  should  be  self-documenting. 

P.  The  system  for  assigning  names  to  equipment,  a -iJ<  v 
sensors,  DDC  loops,  etc.  and  for  parameter! ::i nr  tlr 
data  acquisition  and  PPO  programs  should  be  integrated 
the  sequencing  language,  so  that  names  and  addresses 
need  not  be  specified  more  than  once. 

E.  The  user  should  be  thoroughly  grounded  in  logic  and 
industrial  Application  concepts  in  order  to  use  ary 
sequenc i ng  1 anguage . 

5.  That  a large  number  of  process-oriented  compiler  din  - 
nostics  should  be  provided,  concerning  the  improper  us 
of  equipment  or  DDE  Loops,  or  general  specification,  or 
programming  errors. 

That  these  diagnostics  inform  the  programmer  of  such 
things  as: 

i.l  Ycm  have  tried  to  close  a non-existent  valve. 
b . ? You  have  illegally  connected  a I1DC  loop  output  to  a 
! solenoid  valve. 

i 
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5.5  You  have  used  the  same  analog  sensor  name  twice,  or 
the  same  input  channel  number  twice. 

And  many  others. 

6.  The  following  additional  functions  have  been  recognised 
as  being  necessary  or  at  least  desirable  for  sequence 
control: 

A.  Turn  on  a two  state  device  (name) 

B.  Turn  off  a two  state  device  (name) 

C.  Change  state  of  a two  state  device  (name) 

D.  Pulse  out  (direction,  magnitude,  name) 

E.  Position  (magnitude,  name) 

F.  Activate  loop  (initial  position,  set  point,  delay  time) 

G.  Deactivate  loop  (final  position) 

II.  Function  Generator  (function  no.,  cut  off  point) 

T.  Change  control  loop  parameter  (loop  no.,  parameter,  valu-' 

J.  Delay 

K.  Change  scan  frequency  (point  no.,  frequency) 

L.  Demand  analog  scan  (point  no.) 

M.  Demand  digital  scan  (point  no.) 

N.  Set  alarm  limits  (point  no.,  high/low,  value) 

O.  Arithmetic  capability 

P.  Initiate  man-machine  communication  (function  no.' 

Specify  and  terminate  repetitive  logs  (log  no.  and 
time  interval) 

K.  Specify  alarm  conditions  for  possible  action 
digital  or  analog  actuated  (alarm  list  no. 1 


either 
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S.  Capability  to  confirm  results  of  dif.it  a • -rid  a 1« 
control  actions. 

T.  Capability  to  retry  a digital  action. 

U.  I race  and  snapshot  requests  aval lab 1 ■ f r diagnosl 
and  debugging  purposes. 


S ub f unc t i on  call s . 
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TV.  RECOMMENDATIONS 

A committee  should  be  established  which  would  define 
standard  functional  requirements  of  programming  packages 
for  such  areas  as  data  collection  and  man-machine  eomrr.ur - 
cation.  Other  areas  could  include  Digital  scan,  control, 
logging,  alarm  action  and  computer  to  computer  communication . 
Error  diagnostics  should  at  this  point  continue  to  be  a 
functional  area  or  a committee  at  the  standardised 
software  workshop  meetings. 

The  evidence  available  indicates  that  at  present  neither 
of  the  two  languages  being  discussed,  the  procedural 
language  and  the  format  defined  language,  will  satisfy 
the  functional  requirements  of  sequence  control.  It  is 
recommended  that  the  functional  requirements  of  sequence 
control  be  considered  by  a committee  which  concerns  itself 
with  the  general  question  of  a problem  oriented  language 
for  process  control,  rather  than  a format  defined  langunr. 


* 
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SECTION  IV 


FUNCTIONAL  NEEDS  FOR  REAL-TIME 
ENHANCEMENTS  TO  MINIMAL  BASIC 


One  of  the  first  tasks  of  the  Industrial  Real-Time 
BASIC  Committee  was  to  develop  the  attached  list  of  specific 
functional  requirements  for  that  language.  This  report  was 
published  as  pp . 197-205  of  the  Minutes  of  the  Second  Annual 
Meeting  of  the  International  Purdue  Workshop  on  Industrial 


Computer  Systems. 


FUNCTIONAL  NEEDS 


RE  A L - T I ME  ENHANCE  ME  NT : '» 


MINIMAL  BASIC 


Prepared  by  the  Industrial  Real-Time  BASIC  Committee  of  the 
International  Purdue  Workshop  on  Industrial  Computer  Systems 

Van  Diehl,  Chairman 

Horst  Hailing,  Chairman,  European  Croup 

Thomas  M.  Bell 

Philip  Stein 

John  Herbster 

Dave  Herman 


George  Janjecic 
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TAPLE  IF  CONSENTS 

Introduction 

Process  Input-out' at 
1.1.  Anal  * rn  u‘-  ’u*.  ’ ;r 
.2.  : ' : -i'  a : : ■ ‘!'i  -.tout 

2.3.  Pul ' re  put 

5.  Access  to  System  Time  and  ^ate. 
u.  Multiple  Character-devices 

Extension  of  Control  Statement 

6 . Extensi<  n of  Data  Types  and  p<  rat  ! )ns 

7.  External  Subroutines 

8.  Extension  to  Error  Handling 

i.  File  Handling  and  Interprocess!  r Co mnica 
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1 . Intro  duct  .1  on 

The  BASIC  features  which  have  made  the  language  sucre 
ful  in  different  application  areas  also  apply  for  a class 
real-time  applications.  A great  number  of  implementations 
already  exist  that  use  various  extensions  to  meet  real-tin 
needs.  This  document  is  an  attempt  to  define  the  common  r 
quirements  of  the  real-time  user. 


The  following  diagram  is  an  illustration  of  a possifcl 
real-time  system: 


tax  exa  j - ss  1 : ed  ii  this  documenl  ar<  . foj 
Lustrati  n and  ar<  n 1 pari  f the  pr  posal. 


- 102- 


2 . Process  Input-Output 

Process  input-output  functional  interfaces  allow 
the  access  to  specified  analog  and  digital  inputs  and 
outputs.  All  the  process  input-output  operations  are 
executed  in  direct  response  to  the  corresponding  state- 
ment . 


2.1*  Analog  input-output 

The  parameters  needed  for  these  operations 
are  specifications  of: 

(a)  The  hardware  channel (s) 

(b)  Access  Mode  (random,  sequential,  etc.) 

(c)  Hardware-software  conversion 

(d)  Error  information 

The  data  transferred  over  the  analog  input- 
output  interface  will  be  represented  in  standard 
floating  point  form* 

2.2.  Digital  (discrete)  input-output 

The  parameters  needed  for  these  operations 
are  specifications  of: 

(a)  Digital  I/O  point  or  series  of  points 
(discrete  I/O  channels) 

(b)  Hardware-software  conversion  information 

(c)  Error  identification  information 


The  data  transferred  may  be  to  or  from  a standard 
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floating  point  variable  or  a bit  string  variable 
(see  Section  6 ) . 

2-3-  Pulse  (train)  input-output 

The  parameters  required  for  these  operations 
are  specifications  of: 

(a)  Channel(s) 

(b)  Hardware-software  conversion  information 

(c)  Error  identification  information 

3 ■ Ac co s s to  System  Time  and  Data 

The  current  time  must  be  available  to  Real-time 
BASIC  programs  for  use  in  calculations  and  logging.  It 
must  giv  date  (year,  month,  day)  and  time  information 
(hour,  minute,  seconds). 

'*  • Multiple  Terminal  I/O 

Process  Control  configurations  are  usually  not 
limited  to  a single  system  console.  System  configuration 
ft. on  Includes  teletypes,  line  printers  and  CRT's.  An 
example  is  the  need  to  print  test  results  in  terminal 
printers  local  to  tests  being  performed.  There  is  there- 
f >re  a need  to  extend  the  PRINT  and  INPUT  statements  to 
include  the  specification  of  the  target  devices.  Operator 
and  l 'V I ’•  errors  In  response  to  INPUT  statements  shouldn't 


fatal . 


Example  : 


Print  #6  ; < variable  list  > 

5 . Extension  of  Control  Statements 

Minimal  BASIC  includes  control  statements  that 
sllow  for  the  interruption  of  the  normal  sequence  of 
execution  of  statements  by  causing  execution  of  a specit: 
line,  rather  than  at  the  one  with  the  next  higher  line 
number . 

Real-time  BASIC  requires  extension  of  the  control 
statements  to  allow  for  the  causing  of  the  execution  of  a 
specified  line  number  by  an  elapsed  time  having  occurred, 
at  a specific  time  of  day,  upon  the  occurence  of  an  exter 
al  event  or  error  condition.  Statements  that  enable  or 


disable  the  action  of  s 

uch  control  statements  are  al 

so  a 

desirable  fea 

ture . 

Examples 

of  these 

extens 

;ions  are: 

(1) 

Execute 

"line 

number"  after  5 second 

delay 

(2) 

Execute 

"line 

number"  at  10  aw. 

(3) 

Execute 

"line 

number"  when  contact  5 

close 

(4) 

Execute 

"line 

number"  if  any  terminal 

key 

Is  struck. 

6 . E xtens  1 or i . to  Data  Types  and  Operations 


The  number  of  data  types  in  Real-time  BASIC  should 
be  kept  to  a minimum.  Tn  the  proposed  "Minimal  BASTS", 
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two  data  types  exist.  The  data  type  floating  point 
variable  and  the  data  type  character.  The  correspond i ng 
data  structures  built  of  these  data  types  are  array 
(1  or  2 dimensional)  and  string. 

Manipulation  of  analog  and  digital  I/O  data  car,  be 
done  using  the  standard  floating  point  representation. 
Approprate  conversion  routines  in  analog  and  digital  I/O 
statements  will  convert  discrete  (digital)  inputs-outputs 
into  the  internal  machine  representation.  In  this  form, 
no  integer  representation  will  be  required.  However,  a bit 
string  data  structure  is  strongly  desirable,  especially  in 
applications  in  automatic  digital  testing  where  large  bit 
strings,  in  the  order  of  hundreds,  are  required.  In 
summary,  the  following  process  data  have  to  have  internal 
representation  in  the  BASIC  system: 

(1)  Analog  input-output  - Values  can  be  represented 
by  standard  floating  point  variable. 

(2)  Digital  input/output  - The  bit  pattern  of  physical 
"0"  or  "1"  combination  can  be  represented  by  a 
string  of  "0"  or  "1"  in  a bit  string  or  by  an 
equivalent  floating,  point  representation. 

Additional  operations  are  required  to  manipulate  internal 
representation  of  external  discrete  process  data.  The  Boolean 
operators  needed  are: 
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AND,  OR,  NOT,  exclusive  OR,  SHIFT,  BIT  TEST/SET/CLEAR 

These  operations  should  be  defined  as  functions  return- 
ing a bit  string  result. 


7 . External  Subrout i nes 

Calls  to  user-generated  subroutines  that  are  external 
to  the  BASIC  system  should  be  provided. 


Example : 

400  CALL  HEL1  (c-rr,,  err,,,  . ..) 

8.  Extens ion  to  Error  Hand  1 j nr 

A very  important  consideration  in  the  use  of  real-time 
BASIC  in  industrial  applications  is  the  type  of  error  hand- 
ling capability  that  should  be  provided  in  the  language. 

Whenever  errors  occur  during  BASIC  program  execution 
(such  as  overflow,  incorrect  data  input,  I/C  errors,  etc), 
they  should  result  in  the  setting  of  an  error  flag.  Such 
an  error  flag  may  be  tested  by  an  extension  ?f  the  control 
statement  of  the  form: 

5 ON  ERROR  GOTO  (GOSUB)  100 

A scheme  will  be  provider  to  allow  the  .ia  n-  u iderC 
the  error  cause. 


1 
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9 . File  Handling  and  Interprocessor  Communication 

There  are  strong  requirements  for  file  handling  in 
measurement  and  control  applications.  These  are  similar  to 
the  ones  that  are  being  considered  by  the  X3J2  Application 
Oriented  Committee  on  Science.  It  is  important  that  the 
standard  syntax  for  file  manipulation  could  be  extended  to 
access  files  that  may  be  resident  on  the  mass  storage  of  a 
remote  computer  in  an  distributed  system  network.  The  same 
remarks  apply  to  chaining,  where  program  chains  may  be  resi- 
dent in  the  same  computer  mass  storage  device  or  in  the 
central  computer  in  a distributed  system  network. 


| 

J 


* 


mm m 


1 


-109- 
SECTION  V 

FUNCTIONAL  GUIDELINES  FOR 
INDUSTRIAL  CONTROL  COMPUTER  SYSTEMS 


One  of  the  very  early  documents  of  the  ISA  Computer 
Control  Workshop  developed  in  1963-64  was  a preliminary 
version  of  the  document  listed  above.  This  was  reviewed 
and  expanded  for  consideration  at  the  First  Purdue  University 
Meeting  of  that  Workshop  in  May  1972  and  published  in  the 
Minutes  of  that  Workshop  as  Appendix  II,  pp . 33-189. 
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FUNCTIONAL  GUIDELINES  FOR 
INDUSTRIAL  CONTROL  COMPUTER  SYSTEMS 


A Proposal  for  Consideration 
at  the  1972  Meeting  of  the 

ISA  COMPUTER  CONTROL  WORKSHOP 

Purdue  University 
Lafayette,  Indiana  47907 
May  22-24,  1972 


December  1971 


Purdue  Laboratory  for  Applied  Industrial  Control 
Schools  of  Engineering 
Purdue  University 
Lafayette,  Indiana  47907 


J.  BUKtrKT 


At  the  April  2;  -25,  1973  meeting  • f the  Computer  C ntr 
Workshop  (succession  to  the  Workshop  on  Direct  Digital  Computer 
Control  (15))  it  vas  suggested  that  sufficient  time  had  passed 
so  that  the  Guidelines  and  Questions  and  Answers  document  • f 
the  original  Workshop  required  dification  and  updating.  The 
facilities  of  Purdue  University  were  offered  for  holding  the 

required  new  Workshop  and  the  date  . f May  9-12,  1972  was  pr, roe 

The  attached  proposal  will  be  used  as  the  initial  discuss' 
point  for  this  new  Workshop. 

In  developing  the  overall  system  to  be  proposed  here  a 
major  if  not  verriding  consideration  must  be  the  reduction  f 
personnel  requirements  to  implement  an  installation  in  terns 
of  the  original  engineering  layout,  the  mathematical  modelling 
and  control  strategy  development,  the  coding  in  an  appropriate 
programming  language,  and  finally  the  checkout  and  testing,  f 
the  final  installation.  Other  important  considerations  are  de- 
veloping the  maximum  overall  reliability  of  the  resulting,  sysl  • . 
the  minimum  total  cost  at  final  commissioning,  as  well  as 
mum  flexibility  and  ease  of  making  post-commissioning  char 

TASK  ASSIGNMENTS  ANT  HARDWARE  FEATURES 

Figure  1 outlines  the  hierarchy  organisation  which  ccm- 
p rises  the  largest  scale  vorsi  n of  , ur  proposed  standard  pr<  - 


cess  :ontrol  computi  r system.  Level  One  and  Level  Two  macl  '■ 
are  very  similar  in  function-differing  only  in  the  extent  f lee 
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control  function.;  ass  i .■'nod  to  each.  The  dedicated  digital 
controller  os’  Level  One  handles  complex  devices,  including 
chemical  analyzers  such  as  chromatographs,  and  specialized 
feedforward  and  noninteracting  - multivariable  control  set- 
UPS • The  direct  digital  controller  of  Level  Two 

handles  a much  larger  number  of  three-mode  and  related  type 
control  loops (if).  It  also  communicates  with  the  plant 
operator  through  a console,  composed  of  cathode 

ray  tubes  and  a keyboard.  Communication  between  all  digi- 
tal computers  and  with  all  consoles  is  by  digital  signals. 
Connections  to  analog  signals  are  required  only  of  the 
first  and  second  level  machines. 

Table  I specifies  some  of  the  assignments  of  tasks  with- 
in the  hierarchy  which  are  necessary  to  achieve  the  simpli- 
fication of  system  and  function  which  it  is  possible  to  de- 
velop here.  Table  II  presents  some  of  the  desirable 

features  of  the  machines  to  be  used  themselves  while  Table 
III  does  likewise  for  the  other  elements  of  the  total  system. 

In  order  to  achieve  our  main  object  of  reducing  overall 
systems  cost  and  of  simplifying  greatly  the  engineering,  in- 
stallation, and  commissioning  of  an  industrial  control  sy- 
stem, it  is  necessary  to  modify  greatly  the  previous  organi- 
zation of  the  data  collection  and  conversion  and  the  control 
correction  output  distribution  parts  of  the  system.  In  place 
of  the  previously  common  methods  of  using  individual  pairs 
of  leads  between  sensor  and  central  processer  and  between  pro- 
cessor and  final  actuator  we  wish  to  adopt  the  concepts  recently 
perfected  by  the  aerospace  industry.  This  is  to  use  a set  of 
remote  multiplexers  and  a single  "data  highway"  carrying  only 
digital  signals  between  these  multiplexers  and  the  computer 
itself  (6).  Such  a concept  has  been  technically  possible 

for  sometime  (7).  However,  only  recently  has  integrated  cir- 
cuitry made  remote  multiplexers  and  multiple  A/D  converters 
economically  practical  and  computer  systems  fast  enough  to 
handle  the  data  load  necessary  for  the  method  of  operation  of 
the  system  which  is  to  be  proposed  here  (2, -3,5). 

Figure  2 diagrams  the  data  collection  and  conversion 
part  of  the  system  under  discussion.  Table  IV  outlines  our 
requirements  for  its  design  and  operation  considering  such 

(Text  continues  on  page  -125-) 
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TABLE  I 

ASSIGNMENTS  OF  TASKS  WITHIN  THE  CON TOOL 
HIERARCHY  AS  IT  AFFECTS  THE  STANDARD 
PROCESS  CONTROL  COMPUTER  SYSTEM 


| 

I 

I I 


1.  Level  One  and  Two  Machines  will  be  confined  to  tasks 
of  data  collection  for  higher  members  of  the  hierarchy 
and/or  to  dynamic  control  of  the  plants. 

2.  All  large  scale  optimization  functions,  particularly 
those  comprising  large  linear  programs , will  be  carried 
out  on  Level  Three  or  higher  machines. 

5.  Non-control  hierarchy  related  accounting  functions  and 
engineering  or  other  off-line  work  will  be  carried  out 
on  third  or  higher  level  machines.  But  then  only  when 
absolutely  necessary.  Generally  this  work  should  be 
confined  to  separate  unrelated  equipment. 

4.  Compiling  and  related  program  preparation  tasks  will  be 
carried  out  on  Third  Level  or  higher  machines  or  on  unre- 
lated off-line  equipments. 
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I'ARI.K  II 

MINIMUM  REQUIRED  CHARACTERISTICS  AND 
CAPABILITIES  OF  COMPUTER  MAINFRAMES  USED 
IN  THE  PROPOSED  STANDARD  PROCESS  CONTROL 
COMPUTER  SYSTEM 


1.  Lower  level  machines  in  the  hierarchy  should  have  only 
internal  read-write  or  read-only  memories  to  assure 
maximum  reliability. 

2.  All  mainframes  should  have  parallel  organization  and 
state-of-the-art  speeds.  They  should  also  have  suffi- 
cient built-in  hardware  facilities  to  make  their  pro- 
gramming by  off-line  means  readily  feasible. 

3.  Interface  equipment  must  be  designed  and  built  to  the 
same  quality  and  reliability  specifications  as  for  com- 
puter mainframes. 

4.  Maximum  reliability  considerations  must  bo  handled  by 
fault  tolerant  designs,  dual  systems,  or  established  fai  1 - 
upward,  backup  arrangements  for  all  machines  carrying  out 
dynamic  control  functions. 
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TABLE  III 

SOME  PROVISIONS  OF  SYSTEM  (NON-COMPUTER) 

HARDWARE  USED  FOR  STANDARD 
PROCESS  CONTROL  COMPUTER  SYSTEM  FOR 

INDUSTRIAL  COMPLEXES 

1.  Single  sensors  and  single,  twisted,  stranded,  shielded 
pairs  of  lead  wires  shall  be  used  for  each  analog  point 
read.  Where  redundancy  is  required  for  safety  this  will 
be  by  entirely  separate  sensors  and  sets  of  lead  wires 
to  the  process  location. 

2.  Remote  multiplexers  will  be  distributed  about  the  plant 
in  such  a manner  that  the  longest  sets  of  analog  lead 
wires  shall  be  in  the  order  of  100  feet  or  less. 

3.  All  switches  shall  be  solid  state  and  will  be  designed 
such  that  all  failures  will  cause  a "fail  open"  condition. 

4.  All  switches  shall  be  dual  giving  two  separate  data  paths 
through  them.  Each  arm  should  be  separately  testable  by 
an  external  signal  to  permit  determination  of  a possible 
failure  condition. 

5.  Each  remote  multiplexer  shall  be  equipped  with  its  own 
A/D  and  D/A  converters  to  permit  digital  communication 
throughout  the  remainder  of  the  data  system. 
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TABLE  ITT  ( CO.'.T . ) 

6.  All  remote  multiplexers  attached  t ; ne  direct  digit- 
control  center  shall  be  connected  tc  their  ccrrosp.  nd- 
ing  computer  systems  by  a single  data  path  consisting 

of  three  coaxial  cables;  one  f<  r data  in  ; one  f r lata 
out ; and  one  for  timing.  Inquiries  and  ther  perati  nal 
signals . 

7.  Redundant  signal  paths  may  be  supplied  if  r<  lial  13  ■ 
requirements  so  dictate.  Such  paths  should  be  rout! 
spaced  sufficiently  far  from  th-  primary  path  i:n  f n 
single  accident,  natural  disaster,  or  act  of  minor  sa- 
botage :an  sever  both  paths. 

8.  System  power  shall  be  supplied  from  a backup  power  sy- 

stem such  as  an  amplidyne  plus  gas  engine  driven  motor 
generator,  by  a battery  system  floating  on  line  or  by 
another  equally  capabl  > system,  fuch  ba'-gUp  must  1" ■ 
capable  of  keeping  tl  systen  perati  wit  ut  it  ir- 

rupt i or  wi  tl  ui  :aus  1 1 g syst  ei  error  for  one  1 ir 
twic  * the  mean  repair  tl”:1,  whi  :h<  vi  r is  1 i ••  r. 

9 . All  maintenance  si  : be  carried  out  under  a philosophy 

of  re]  1 :eme  * f the  tompent  with  a spare  with  sub- 
sequent fault  analysis  and  repair  off-line.  Phus  pares 
must  I maint  it  : of  a 4 ms  1 ; ■ sys ' < n wi 

be  (:  nsidered  minimum  ••n-  'it  i"S  an’  v:!i>  .•<>  fault  caua4-.  • 


failure  can  be  so  identified  as  to  unit  involved  and 
thus  readily  pinpointed.  Appropriate  levels  might  be 
complete  chromatographic  instruments;  mini-computer 
mainframes;  computer  memory  modules  if  specific;  A/D 
converters;  multiplexer  modules;  etc.  Use  of  manufac- 
turer supplied  spares  and  maintenance  personnal  may 
have  to  be  involved  in  such  work  because  of  proprietary 
or  commercial  interests  or  contractural  arrangements 
arrived  at. 

10.  Single  output  transducers  and  single  output  units  shall 
be  fused  for  each  control  point  unless  very  stringent 
reliability  requirements  dictate  the  use  of  multiple 
control  elements. 
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TALLE  l'V 


REQUIREMENT!!  ON  OPERATION  01' 

PRODUCTION  CONTROL  COMPUTER  SYSTEMS  FOR  AN 
INDUSTRIAL  COMPLEX 

1.  System  will  be  operated  in  such  a way  that  a redundant 
or  a fail-upward  backup  of  any  component  may  be  carried 
out  easily.  This  can  be  best  accomplished  by  polling 
each  separate  point  on  each  separate  remote  multiplexer 
in  turn  on  each  Direct  Digital  Control  Center  until  every 
one  in  each  center  has  been  polled  singly  in  its  turn,  ie.  , 
all  on  Remote  Multiplexer  One  of  Center  One,  all  on  Re- 
mote Multiplexer  Two,  etc.  , then  all  on  Center  Two,  and 

so  forth.  (See  Figure  3) 

2.  All  data  collection  computers  will  be  equipped  with  di- 
rect memory  access  devices  to  permit  storage  directly  it, 
memory  of  the  last  sensor  reading  on  each  point.  This 
is  to  avoid  overloading  the  main  arithmetic  of  machine 
with  routine  tasks. 

3.  The  data  acquisition  system  will  operate  on  a one-tenth 
second  cycle,  ie.  , every  point  is  to  be  read  each  tenth 
second.  This  will  allow  following  even  the  fastest  vari- 
ables of  an  industrial  process. 


4.  Analog  data  will  be  converted  to  a resolution  of  thir- 
teen bits  plus  sign  (14  bits  total). 


TADLT  IV  (CONT.  ) 


5.  Digital  data  will  be  handled  as  14  bit  words. 

6.  Limit  checking  will  be  done  on  entry  into  memory  if 
the  computer  can  be  equipped  with  a comparator  on  the 
direct  memory  access  device.  Otherwise  it  will  be 
done  as  the  first  item  of  data  manipulation  by  the  com- 
puter in  preparing  its  control  computations  from  the 

del  to.  • 


POINT  SAMPLING  FOR  CONTROL  OF 


ANALOG  POINT  1,  MULTIPLEXER  1, 
DIRECT  DIGITAL  CONTROL  CENTER  1 

ANALOG  POINT  2 , MULTIPLEXER  1 , 
DIRECT  DIGITAL  CONTROL  CENTER  1 


DIGITAL  WORD  1,  MULTIPLEXER  1, 
DIRECT  DIGITAL  CONTROL  CENTER  1 

DIGITAL  WORD  2,  MULTIPLEXER  1, 
DIRECT  DIGITAL  CONTROL  COMPUTER  1 


ANALOG  POINT  1,  MULTIPLEXER  2 
DIRECT  DIGITAL  CONTROL  COMPUTER  1 


DIGITAL  WORD  2,  MULTIPLEXER  2, 
DIRECT  DIGITAL  CONTROL  COMPUTER  1 


DIGITAL  WORD  2,  MULTIPLEXER  8, 
DIRECT  DIGITAL  CONTROL  COMPUTER  1 


ANALOG  POINT  1,  MULTIPLEXER  1, 
DIRECT  DIGITAL  CONTROL  COMPUTER  2 


DI  G : ''A!. 
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topiiT.  at;  : *•  T Iti  rate  , da  fa  word  length,  etc.  In  Figure  2 

it  should  he  noted  t.i  1 ■ • i critical  elements  of  the  data  path 
such  as  multiplexer  switches  and  the  A/D  converter  itself  are 
dual  with  independent  operation  so  that  failure  of  any  single 
element  will  not  disable  a particular  input.  We  specify  also 
that  swiches  should  "fail  open"  by  design  (in  contrast  to  the 
usual  operation  of  reed  relays)  and  that  these  elements  should 
be  capable  of  being  tested  independently  during  preventive 
maintenance  procedures. 

Reliability  at  the  Level  1 and  2 computer  ends  of  the 
data  requisition  system  can  be  achieved  by  the  use  of  dual 
computers,  one  in  a use,  the  other  in  a standby  status.  For 
a large  system  such  as  contemplated  by  Figure  1 a single  stand- 
by computer  might  be  used  as  backup  for  all  Level  2 machines 
of  the  complex  as  diagrammed  by  Figure  2.  Again  the  recent 
drastic  price  reductions  of  capable  small  computer  mainframes 
makes  economically  practical  a concept  which  is  not  new  in 
the  industry  (4,10). 

Another  major  concept  of  this  proposal  needed  to  help 
achieve  system  simplification  is  that  all  operator  communica- 
tions will  be  through  a color  cathode  ray  tube  (CRT)  presen- 
tation of  both  .alphanumeric  and  graphical  data  (9,11,1/). 

All  operator  actions  will  then  be  conducted  through  keyboard 
entry  from  this  same  small  console  containing  the  CRTs.  Dual 
CRTs  will  be  specified  with  independent  and  interchangable  func- 
tioning for  reliability  reasons.  No  hard  copy  (printed)  output 
is  contemplated  at  Level  1 on  Level  2 stations.  All  of  this 
latter  can  be  handled  at  Level  3 or  4 locations  when  needed  for 
accounting  or  historical  records.  Acceptance  of  this  part  of 
the  proposal  would  eliminate  the  massive  central  control  rooms 
now  used  by  all  process  industry  plants  with  their  attendant 
major  design,  installation  and  check-out  difficulties.  Figure 
4 sketches  one  concept  of  the  possible  appearance  of  such  an 
operator's  station  for  a Direct  Digital  Control  Center. 

AN  EXAMPLE  SYSTEM  FOR  A LARGE  INDUSTRIAL 
MANUFACTURING  COMPLEX 

If  the  industrial  computer  control  system  contemplated 
here  were  assigned  to  a large  petroleum  refinery  or  petrochemical 


■ 
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c crop  lex  it  m!  ;.i  : <•  r-  sslred  t.  handle  up  to  1500-1800 
analog  input.-  an  1 n o.au  1 :n.n!  er  of  dirital  signals . If 
the  conditions  of  tiic  previous  Tables  are  imposed  an  organ- 
ization and  data  transmission  load  such  as  is  discussed  in 
Table  V results.  Note  that  8 separate  Direct  Digital  Con- 
trol Centers  (Level  2),  each  with  8 individual  remote  mul- 
tiplexer stations  are  proposed  as  an  example.  The  remote 
multiplexer  stations  may  or  may  not  each  contain  one  or  more 
Level  1 computer  systems  - this  would  be  a function  of  the  plant 
unit  involved  and  its  own  chemical  analysis  and  advanced 
control  system  requirements.  A single  Level  3 unit  is  en- 
visioned here  for  purposes  of  discussion. 

Please  note  that  Table  V assumes  that  the  socalled 
"data  highway"  will  be  composed  of  three  separate  coaxial 
leads,  one  for  data  input  to  the  Control  Center,  one  for 
control  correction  outputs  back  to  the  process,  and  the 
third  for  system  timing  and  selection  signals.  While  one 
coaxial  cable  could  probably  easily  handle  the  load  contemplated 
here,  the  use  of  three  simplifies  greatly  the  computer  pro- 
gramming problem  without  appreciable  physical  cost  increases. 
Note  also  that  the  control  correction  and  timing  networks 
will  be  very  nearly  duplicates  of  the  data  acquisition  net- 
work of  Figure  2 

Plants  which  do  not  require  as  elaborate  a system  as 
is  called  for  in  Figure  1 can  still  make  use  of  the  con- 
cepts outlined  here.  Use  of  Level  Three  or  Four  machines 
should  always  imply  the  existance  of  the  lower  members  of  the 
hierarchy  if  only  in  a data  collection,  ie,  noncontrol,  func- 
tion. The  reverse  case  is,  of  course,  not  true  since  a Level 
Two  machine  can  very  well  stand  alone  in  an  appropriate  plant 
process  control  situation.  The  Level  Three  machine 
must  have  a source  of  plant  data  and  this  might  just  as  well 
be  collected  by  sublevel  digital  systems  as  by  means  of  plant 
input  fed  into  an  interface  system  which  is  part  of  the  Level 
Three  machine  itself. 

For  systems  which  do  not  recuire  a Level  3 station  it 
may  be  necessary  to  specify  a hard  copy  device  at  the  Level  2 
location  to  provide  the  accounting  and  historical  records 
which  are  necessary  for  the  proper  operation  of  the  plant. 

(Text  continues  on  , age  -130-) 
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TAPLE  V 

DATA  LOAD  PER  PRODUCTION  CONTROL  COMPUTER 
SYSTEM  (LEVEL  3)  FOR  AN  INDUSTRIAL  COMPLEX 

I Total  System  Load  if  Centralized  for  any  Purpose 
1.  Data  Input  from  Process 


a. 


b. 


Analog  Inputs  from  Process 
(8  X 240)  = 1920 

Digital  Input  Points  from  Process 
(8  X 224  ) = 1792 

Data  Rate 

[(1920  X 14  ) + (1792  )] 10  = 286,720  bits/second 


Data  Output  to  Process 

a.  Analog  Outputs  to  Process 

(8  x 120 ) - 960 

b.  Digital  Output  Points  to  Process 
(8  X 112)  = 896 


Required  Data  Transmission  Load 
Assuming  0.1  Second  Cycle 

a.  Analog  Input 

(1920  X 14  )=  26,880  bits 

b.  Digital  Input 

(1792  X 1)  = 1 ,792 


Total  Input  28,672  bits  per  cycle 

or  286,720  bits/second  input  with 

polled  burst  mode  operation 


Analog  Output 

(960  X 14 ) = 13,440 


d.  Digital  Output 
(896  X 1 ) 


896 


Total  Output  14,336  bits  per  cycle 

or  143,360  bits/second  output  wi  t 

polled  burst  mode  operation. 
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TABLE  V (CONT.  ) 


II  Direct  Digital  Control  Centers  per  F'roductor  Control 
System  Center  (Level  1)  - 

8 Direct  Digital  Control  Centers  per  Production 
Complex  Control  System 

256  Total  Data  Words  Input  Each 
2^0  analog  points 
224  digital  points  ( 16  X 14  ) 

128  Total  Data  Words  Output  Each 
120  analog  output 
112  digital  output  (8  X 14 ) 

Plus  all  local  requirements  for  system  operation 
and  operator  communication. 


Ill  Remote  Multiplexer  Stations  per  Direct  Digital  Control 
Center  (Level  1 and  at  Process)  - 

8 Remote  Multiplexer  Stations  per  Direct  Digital 
Control  Center 

32  Total  Data  Words  Input  Each 
30  analog  points 
28  digital  points  (2  X 14 ) 

16  Total  Data  Words  Output  Each 
15  analog  output 
14  digital  output  (1  X 14 ) 

A/D  Converter  Conversion  Rate  Assuming  Polled 
Operation  and  Burst  Mode  Becomes 

2048  X 10  = 20,480  equivalent  conversions 

per  second  allowing  equal  polling 
time  for  digital  point  words 

Required  A/D  Conversion  is  14  bits  (13  bits  data 
plus  sign) 
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As  mentioned  earlier,  complete  reliability  of  all  dyna- 
mic control  functions  is  an  absolute  necessity.  This  cat 
achieved  by  fault  tolerant  design  tec  tniaues,  by  redund 
the  equipment  used  Itself  such  as  master-slave  syst  im  . r b; 
allowing  higher  members  of  the  hierarchy  t<  take  over  tl 
functions  of  lower  members  which  have  failed.  The  int<  rest£ 
simplifying  the  programming  task  would  favor  th  second 

PROGRAMMING 

In  order  t<  achieve  our  < verall  system  obj  ;c1  Lv  ;s  : ; 
regards  programming  items  listed  in  Tab!  • VI  ar  neci  - 
sary.  Fortunately  a major  advance  in  this  direction  is  al  - 
ready  underway  with  the  results  to  date  of  the  Workshop  n 
Standardization  of  Industrial  C mputer  Langu«  |es  (l).  •• 

group  has  proposed  that  the  standard  compiler  level  1 angr1  ;■ 
be  A.'.V I Standard  FORTRAN  augmented  by  a set  of  standard:'  • ■ 
’ALL  statements  to  allow  the  additional  functions  -cesf 
f<  r process  control.  Another  key  feature  < f our  proposal  h i 

is  the  elimination  of  compiling  end  other  pr  gramming  f<  al  ir 
fron  the  presumably  small  First  and  Second  Level  m;  ■■  in<  s. 
This  work  w uld  be  carried  out  on  higher  Level  members 
'■  ierarehy  r < ther  larger  t ff-line  machines  ( 1 ). 

It  should  bo  specifically  noted  at  this  p Lnl  thal  no 
requirements  are  placed  on  stai  lardi  nation  < f a;  :hine  s] 
r hardware  characteristics.  \i  / c mpul  :r  may  be  used  ’ r 
any  < f th  • t as ks  inv  Lv  :d  n ng  its  reliabllil  y, 

f rxibility,  speed,  and  ■ . i ■ • racteris tics  mate  t 
desired  and  - m st  i:p  rV  1 - a unfa  tur-er  a.  i 

k ■ exeeut ive  programmi  ‘f-line  pr  ;rai  rati 

bill ties  called  for  1 r . 

It  should  a Is,  be  ! d « . V tho  } r .•*  • • d -l: 

desired  also  achieves  an.  I ■ nry  bi  1 

Industries  - that  c f pr.  gram  t.r  a • ' a ■ ' 1 ' ' . . 
j ram  w ri  tten  in  ot  or  otl  r of  the  big 
Ifii  d ■ • rai  be  ru  i ai  . machii  ■ w so  r 

if  with  the  necessary  pvegra ibilify  'ill  d ' - >• 

(Text  continues  on  page  -136-) 
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TABLE  VI 

PR'- 'ORAMMTi.'u  iPPUTREMEIITP  1V-P  AC | i a a/TPl 
A DESIRABLE  STANDARD  FROCKS:'  COMPUTER  JTROL  ; SYSTEM 


A high  level  compiler  type  language  or  one  of  a very 
small  number  of  problem  oriented  languages  must  be 
*se<3  for  all  user  group  conducted  program!  ing,  F r 
example,  a Language  which  includes  ANSI  Standard  I 
(>:•  . >-lpo6)  as  a subset  admirably  satisfies  such  a need 

(S). 

* : igh  level  process  :oi  tr<  1 programming  langus  :•  • 
uld  :ontain  the  necessary  iapabilities  t<  permit 

* following  industrij  control  ‘unctions  to  be  pro  - 
gramm< id  ■ , mpl - te  l y in  this  anguage: 

a)  Bit  Manipulation 

b)  Bit  Testing 

••*)  Process  Interrupt  r Priority  Handling, 

d)  Interrupt  Inhibit  and  Permit 

e)  Parallel  Task  Execution 

f)  Pile  a and  1 ing 


g) 

: xte rna  1 Ana  to; ; and 

Di  i ; Data 

Input 

aid  Outpu 

Goal 

< f ■ ft  wa  re  design 

s r i.  uld  be  ti 

mi  irai 

:e  the  a- 

r.oui . 

t of  specific  infi  r: 

, : w i :1 

a p r<  :nss  en.  *1 1 a 

needs  U know  about  a c-ntrei  computer  and  its  asso- 
einiod  software  to  i:t»p  ' t-'-enl  computer  eontia.  for  a 

w t an*  . 

:ess  • tr  j r ;rai oni a ■ sys  : »n s si  : 
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control  computer  system  as  simple  as  possible, 
b)  Contain  an  organizational  method  by  which  the 
user  can  carry  out  any  functions  possible  with 
conventional  control  systems  with  only  a very 
minimum  knowledge  of  programming  such  as  by 
using  a "fill  in  the  blanks"  technique, 
c.)  Preserve  at  least  as  much  compatibility  between 
the  control  practices  of  different  industries  as 
is  possible  with  conventional  analog  control 
hardware. 

d)  Permit  on-line  addition  or  deletion  of  inputs, 

control  computations,  and  outputs,  and  changes  of 
coefficients,  without  recompilation  or  reassembly. 

5.  Provisions  must  be  available  to  compile  all  languages 
of  Item  1 above  on  larger  computers  than  the  object  ma- 
chine of  the  control  application  in  question. 

6.  Assembly  or  machine  language  programming  must  be  re- 
stricted to  specific  functions  which  are  part  of  the 
problem  oriented  language  features  and  which  are  car- 
ried out  by  the  manufactures  or  system  house  producing 
the  control  equipment. 

7.  All  component  computers  of  the  overall  system  except 
those  dedicated  to  very  special  first  level  tasks  must 
have  sufficiently  powerful  executive  pro, ’rams  to  per:;. ' t. 
the  ready  change  of  parameters  through  operators*  • n- 
soles  or  the  action  of  higher  level  computers  in  the 

L 
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system.  Provision  must  be  made  for  complete  and 
accurate  documentation  of  all  such  changes.  This 
executive  should  be  produced  by  the  manufacturer 
or  systems  developer. 

8.  Software  systems  should  be  devel  ped  In  a modular 
fashion  to  the  maximum  extent  possible  with  the 
functions  of  the  modules  rigidly  defined.  These 
modules  should  communicate  through  tables  to  the 
extent  possible.  Table  format  should  be  such  that 
they  will  permit  substitution  of  complete  blocks 
as  newer,  more  efficient  forms  are  developed  and 
reassembly  of  the  program  without  the  necessity  of 
reworking  the  other  blocks.  Figure  5 presents  one 
form  which  such  a system  might  take.  This  will 
permit  standardized  software  to  be  used  in  a multi- 
computer system. 
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The  goal  for  the  standardization  effort  can  be  stated  as 
follows  ( l) : 

"As  a long  term  goal  it  should  be  unnecessary  for  user 
company  systems  and  instrumentation  engineers  and  pro gramim  rr 
tv  have  a knowledge  of  the  basic  machine  language  of  the  com- 
puter involved  or  even  of  an  assembly  language  for  this  iviahlr  . 
However,  they  must  be  thoroughly  grounded  in  computer  and  con- 
trol concepts.  They  should  be  able  to  communicate  with  tl  sy- 
stem, construct  new  programs , and  initiate  or  modify  the  samp- 
ling sequences  and  data  manipulation  techniques  through  tin  use 
of  a standardized  high  level  language,  through  the  use  f a 
specialized  process  control  program  which  can  handle  sin/t 
tabular  formats,  and/or  through  an  operator's  cons-,  le  in 
e iua  1 1 y s imp  le  marine  r . 

Programming  systems  adopted  should  also  have  as  hi.  r-n 
goals  machine  and  configuration  independence.  They  should, 
addition,  contain  provisions  for  automatic  or  semiautomatic  d - 
cumentation  of  all  changes  to  systems  program  and/or  sysla"- 
configuration. " 

The  nearly  universal  attention  in  these  and  similar  -f"  >'tr 
toward  the  use  of  higher  level  languages  means  that  the  vend  r 


must 

be  responsible  for  pr<  ducir 
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combinatic  m 

of  computer 
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(!  - 

ware 

and  of  operating:  system  pn 
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manner*  Figure  6 diagr  i s 

this 

situ at 1 ■ -n , 

indicating  4 

l % M 4 

vendor  hardware  and  s ftware  must  supp'ement  each  th-.-r 
:hi  v( ■ an  equi  va  Lent  resu  ' . \ relati  v<  - 1 simj  Le  c mj 


A 


-137- 


requiring  a much  higher  use  of  software  accomplished  fui  .‘tic:  . 
would  thus  be  equivalent,  except  f r speed  of  operating,  with 
a much  more  sophisticated  and  efficient  computer  with  a o 
respondingly  smaller  operating  system.  Present  trends  in  .mall 
computer  architecture  would  indicate  that  the  Type  A machine 
of  Figure  6 would  probably  be  the  more  popular  in  the  future. 
This  is  despite  the  fact  that  most  present  systems  tend  toward 
Type  B. 


I 
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DETAILED  AND  SPECIFIC  FUNCTIONAL  GUIDELINE  ITEMS 

I.  HARDWARE  CONSIDERATIONS 
1.  SCOPE 

1 . .1  General  Requirements 

These  guideline  items  describe  the  nature,  purpose,  re- 
quirements, and  physical  equipment  desired  for  digital 
computer  based  controllers  for  possible  use  as  digital 
control  systems  for  various  sized  processing  units  and/or 
complete  plants.  Such  use  would  have  the  objectives  uf 

reducing  capital  costs  of  plant  control  systems,  and  f 

I 

providing  a greater  flexibility,  reliability  and  adopt- 
ability for  plant  control  functions. 


Since  reduced  capital  cost  is  a major  objective  f . r these 
systems,  the  vendor  is  requested  to  evaluate  the  desir- 
ability of  all  convenience  and  flexibility  features  list'd 
herein  versus  overall  system  costs.  Cost  reductions  si  u d 
bo  secondary  only  to  system  reliability,  on-line  avail- 
ability, and  operability  in  machine  design  cons id era ti . 
Specific  Requirements 

1.21  Since  such  computers  will  normally  operate  « r.  a 
24-hour  per  day,  seven  day  per  week  scheduh  . 
emphasis  must  be  placed  on  an  extremely  high 
"availability"  of  the  equipment  for  continuous 
operation  in  process  control  service  in  normal  i ' 
control  rO' m environments.  This  required  "avail- 
ability" (Gee  Item  . ) should  be  implement-  d l. 
t tie  v m re  f the  f . ILwii  g techniques : 
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l.r 11  An  especially  high  reliability  of  indi vidua' 
components  and  units  of  the  computer  itself. 

1.212  The  possibility  of  preventive  maintenance 
and/or  replacement  of  components  while  the  c.  mputer 
is  operating  "on  line". 

1.215  Cabinet  and  circuit  layout  design  tc  permit 
rapid  and  convenient  troubleshc oting  and  maintenance 
in  event  of  computer  failure.  It  should  be  empha- 
sised that  computer  malntalnabiJ ity  is  much 
important  in  the  applications  considered  hc-e  '-han 
are  the  corresponding  space  requirements. 

1.214  Duplication  or  redundancy  of  certain  Title  1 
parts  of  the  total  computer  control  system  with, 
provision  for  aut-  matic  switch-over  to  standby 
units  in  the  event  of  failure  of  the  primary  W;  rein  -; 
unit. 

l.P  15  Use  of  fault-tolerant,  self-diagnosinc;  r 
self-repairing  type  circuitry  in  the  non—-  mplofdy 
redundant  units  of  the  computer  contr.  1 systo 
The  equipment  sha.V  be  compatible  for  use  wit!  a 
backup  power  supply,  such  as  batteries,  widen  can 
cep  the  somputer  operatii  g with  i Interrupt i 
for  at  least  one  hour  <r  twice  the  moan  repair 
time,  whichever  is  longer,  in  the  event  of  a main 
line  power  failure. 
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The  equipment  described  herein  must  have  the  f '! 
operating  capabilities: 


1.231  Read -in  and  alarm  the  measured  values  cf  a 
specified  group  -f  plant  process  variables. 

1.232  Computation  . f the  necessary  cc  rr<  cl  ive 
trol  action  according  tc  some  established  lynamic 
control  equation  or  equations. 

1.233  A<  tuation  < f final  plant  contrc  1 eler  ei  ts 
such  on  contrc  1 valves  acc< rdin  ; t the  results 
the  computation  ; f Item  1 

L.  3^  Provisiot  for  display  . f selected  pi  nt 
variables  for  plant  operators  information  whore  J 
c<  itrol  computer  system  is  not  directly  ass  • : 
with  another  supervisory  or  optimising  contr 
computer  system  already  equipped  with  s lit 
d i s p 1 a y facilities. 

1 . . •' 1 P r< »vl  s i n for  read-i n of  the  resi ilts 
manually  conduct  d analyses  and  other  plant  tests. 


r :t.\i  iyd  system  deccktptipm 

. 1 Data -Input  Equipim  mt 
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mn  range , a voltage  signal  in  the  mi  1 1 i v>  it  range 
or  a series  of  contact  closures. 

Inp\it  equipment  must  be  compatible  with  either 
mechanical  (mercury  wetted  or  dry  reed)  switching 
for  low  level  signals  or  solid  state  switching  for 
fast  switching  of  high  level  signals. 

If  economics  requires  it  In  order  to  achieve  desired 
switching  speeds,  a preamplifier  may  be  used  u 
each  low  level  (millivolt)  input  prior  tc  scanning 
to  allow  switching  only  of  high  level  signals. 
Overall  system  economics  (total  computer  system 
plus  input)  should  be  the  deciding  factor. 

2.12  it  is  desired  that  all  accuracy  possible  with  pre- 
sent-day electronic  instrumentation  be  retained. 
Therefore,  analog-digital  conversion  system  must 
be  able  to  convert  signals  to  an  accuracy  of  at- 
least  one  part  in  1024  (i.e.  2l  ).  Accuracy  i-.r-. 
be  considered  as  the  result  of  comparing  the  valui 
of  the  input  signal  presented  to  th  cemput  t 
system  data  interface  to  the  process  with  ;.h>' 
number  which  is  finally  stored  in  computer  memory. 

2*13  taintenance  of  the  iccuracy  of  binary  bits  (3 

part  in  10:  4)  is  necessary  in  all  .n  mpul  ing  eletrerh  r. 
tc  maintain  the  above  input  signal  differential  : 
level  t>  ••  -ugh;  ut  the  system  except  as  nonti.  ned 
speci f 1 cal  1 .v  b"  1 w. 


-142- 


1 


2 . .1  -V  Sampling  of  analog  input  information  from  oho nh- 

and  petroleum  type  plants  shall  be  at  such  • rat" 
that  the  memory  location  assigned  to  each  plant 
input  variable  is  updated  at  least  as  often  as 
follows : 


2.141 

A p p r ox  ima  te  ly 

6o^ 

- Once  per 

sec*,  r.d 

. 142 

Apr  rc  xim; itely 

15$ 

- Once  per 

fiv 

i :ro 

App  rc  ximate  1 y 

25$ 

- Once  per 
seconds 

twenty 

In  general,  flow  variables  will  fall  in  Paragrai  . 
2.141,  level  and  pressure  variables  in  : .14 
temperature  variables  in  2. . In  addition,  t'"  ' 
following  special  cases  apply: 

2. 1-44  Composition  Variables  - Approxima t y n<  > 

per  twenty  com t rr 
or  as  often  as 
supplied  1 y d-t-  • ' h 
instrument . 

: . lA5  Manual  Inputs  - Apprc  xim;  ’ one 

[Set  Points,  etc.)  per  second 

■' . 146  State  Variables  - App  roximati  ly  . : 

(Digit  ' 1 Inputs)  per  second 


: the  above  connotation,  sampling  shall  als  incl 

the  operation  of  determining  the  presence  • r an,, 
alarmable  condition  within  the  variab'o  a*  <:  : 


an  appropriate  indication  of  sue!  c.  ridit  1 


Sampling  of  manual 

inputs  at  rates  appn  xi:- 

. i 4- 

once  per  scan  :d  ;i : 

■ i :cessa  ry  : 

i | , ,.(p , j 

ini 

operator’s  sense  < 

P direct  con 

; r : f pi  : 

T'j  !'.■  ■ d"  ' ■ , - 1 1 i i : 

function  o',,  ii  1 

, ^ 
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ac.ceptance  of  this  method  of  control. 

Ope  rat,  r’s  fens-,  lo 

To  permit  ready  communication  between  the  operator  and  the 

control  computer  system,  a console  is  desired.  It  should 

include  the  following  items: 

2.21  Facilities  for  manual  entry  of  set-point  data  fc r 

each  control  loop. 

* 

2.22  Facilities  for  manual  adjustment  of  the  loop  alar 
settings  and  individual  gains  of  each  contre 
mode  for  each  separate  control  loop.  Sine  • 

these  will  be  adjusted  by  more  experienced  persor.ne 
■and  with  less  frequency  than  will  sot  points,  a 
time-shared  or  multiplexed  device  c-uld  readily  bo 
used  for  this  purpose.  This  should  bo  a limited 
access  facility  with  key  lock  or  similar  device. 

2.2l  A device  for  read-out  under  ope rat-  r command  f 
values  of  set  points,  and  of  each  mode  gain  for 
each  control  loop.  A multiplexed  or  time -a  ar-d 
device  may  be  used  here.  Either  a digital  r a 
analog  type  output  may  be  considered.  The  par- 
ticular variable  or  setting  whose  value  is  t bo 
presented  will  be  selected  by  a system  of  switches, 
toggles,  or  similar  devices. 

. * ’f  Facilities  for  manual  movement  and  adjustment 

the  settings  of  the  process  valves  or  other  final 
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plant  control  elements  in  the  event  of  a c aput  e1 
outage  or  input  transducer  failure. 

1.25  Alarm  indication  and  reset  devices.  See  ho:  w 
(Section  2.1)  for  a more  complete  discussion 
alarm  requirements . 

2 .26  A method  of  indication  of  the  value  f any 

of  the  plant  process  variables  under  ot  itr 
facilities  may  ho  li  w accuracy  (~  ) ccnti  minus 

devices  (one  for  each  variable)  and/or  preei  ri  ■ • 

l°t>)  time  shared  or  multiplexed  devices. 

,27  Since  all  aspects  of  manual  it  : ry  ■ f data, 

pc  int  adjustment  and  f read -cut  cf  :;o'  1 • • c_' 

relate  to  the  operator’s  use  and  f 

direct  computer  control,  the  ionsiderati  ns  < f 
Itett  2 . ll  above  apply.  Therefore,  1 1 functi  ns 
of  this  type  must  take  place  within  the  ctv  • sec- no 
period  mentioned. 

. . 3 If  'it  all  possible  in  te  rms  f economic  c ns  id  - 
operator  functions  should  be  carried  out 
< T color,  cathode  ray  tube,  read-out  u:  •!'.•.  '■  it  •' 

should  have  automatic  character  generate  1:  f'ui  ' ' 


as  well  as  ful 1 

veetc  r capabi  1 3 ty.  1 h ;y  . 

iboU  ' 

have  full -page 

buffer  capability  t doc  •• 

!T  - 

puter  system  • v 

•era  11  date-transfer  !oad:in 

• 

;'copi*s  should  ! 

cel f -refresbi ng. 

(\  nsu  le:  shou.l  d be  equipped  w:i  tl  to  e1.,,a  * ■ -a 

- J 
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. - ards,  tei  ! ; i nume ri  ■ ■ ys , and 
wl  ’ ■ :ai  be  used  tc  initiate'  specie 
in  the  system. 

L" ggor 

T(  all  m the  p<  ■ ra : r i r ad  i y f 1 : w the  perati 
the  plant  unit  or  units  being  c ; ntrolled  by  the  dirt  t 
di  ;ita]  ■ ntr<  1 computer,  an  • ti  nal  ;gir  ; d vie  may 

be  required . Suggest-,  d ' il  ir<  s f the  1 r ar 
follows : 

2.31  Logging  of  a number  of  functions  equal  t.  ar;  • 

mately  half  of  the  variables  being  contr-  1 1 < ' 

be  required. 

2.32  ' aversion  of  input  variables  to  engine- 
and  the  development  of  functions  of  sever 
these  variables  will  facilitate  the  • per a-  r' 

use  of  such  data.  Thus,  some  compute  tiv  r fac  'liti 
other  than  the  c ntrol  correct!.,  n irpit^i  - v 
viously  mentioned  would  be  desirable  in  the  ma-hi  • 

A larm  Unit 

An  alarm  unit  should  be  included  in  the  r ra‘  ■'  ■ 

It  should  have  the  foil  wing  characteristic:'  for  m-ixii-vr: 
utility  to  the  plant  operator.  An  alarm  for  eacl  1 p 
being  controlled  is  desired.  The  functi  iescril 
be  incorporated  in  an  operator's  CRT  display  if  desir-  d. 

1.  Tt  should  contain  ne  r more  alarn  sign;  3 . 

This  l i ght  sh  uld  f 1 ish  wh< (never  ne  !' 


is  being  controlled  by  the  computer,  there  sh-uld 
be  a separate  signal  light  for  a :h  | anl  uni 
under  c.  ntr  i! . 

.4;  'it  should  als<  Li  :lude  u audib  alam  which  . 


sound  whenever  any  process  variable  under  c 
reaches  either  the  high  or  the  1 w limit  pr-vl" 
established  f r it. 


2.4;  By  pressing  a si i 1 1 ■ 1 ! butl  n,  tl  ] ral  r - 
acknowledge  his  awareness  of  the  presene  • ft’ 
j Lai  t error.  The  butt<  n wl  I 1 si  1 me  ; 1 audi 
alarm  and  cause  the  light  t coast  f’l.a  shirr, 
ever,  the  light  wil 1 continu<  t shine  ; ■ ■ i 
long  as  the  variable  is  out  f limits. 


. • Once  the  va rl able  is  back  within  Lmits , 1 
v/ill  go  ut. 


. Should  still  an  : ; ;r  varial  tfil  in  sai 

g ut  i f limits  while  the  :ight  is,  bu suing  ' 
it  will  begin  flushing  again  *i:el  • an  Mb'  • •- 
wi ’’  1 s und  again  thus  indicating  a 1 w a ■ r ■ - 

ditl  >r  t>  th»  • pt • rat,  r. 

. Th  lco-ifoi  ti  i usb-vr  • nd  ?<•••  i ••r.al  i n , 11  - 


■■■hoth 
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the  . screen  wl lenever  t s va  riable  joes  oul 
limits . 

. 7 The  pti  nal  alarn  prli  ter,  i f ' used,  she  ild  be 

add  it  i n t<  th<  c jging  typewriter  described  at  ve. 

. 'io  In  order  t 1 -ing  a n<  w perator  up-to-date  f< 
a shift  change,  a method  should  he  provided  f<  r 
reviewing  the  situation  existing  at  that  time  "s 
regards  a Larmed  v<  rial  Les.  ( ne  p<  ss  LI  i y 
have  the  alarm  printer  pr^nt  out  all  off -limit 

va ri ab Les  n dei 3.  Another  j sail  itv  ii 

butt<  n t<  r<  set  a1 1 ala rm<  d c \ di t3  ns  and  thus 
allow  the  alarm  unit  to  reactivate  any  ;larm 
- -nd  it  ions  still  present  at  the  m<  nent  th''s  butt;  i 
is  pressed. 

.19  A separat<  audibl  • signal  and  flashing  ' t 

shall  he  pm  vided  as  part  of  the  alarm  unit  t-> 
notify  the  perat.  r of  computer  system  errors 
fa ilures  such  as  included  under  tei  . . 


• ’.h 


The  Computer 


rhe  c<  mputer  in  i ts  \ a rl  us  pa  *ts  must  p«  ri  rn 
. perat ions  on  input  data,  preparation  V data 
logging  if  usi'd,  and  t • >•  oi  tn  1 compulations 


jv,.  „i-i  ai ■ i ! 

f.  r suh.o'  g;. 


o j a ;•  reliability  ■ id  ■ 1 y . ' : >1  ■ ' 

1 ' as  simple  s ] ssil  e ir  iesigt  and  sonstru 
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Control  Outputs 

System  outputs  frt  m the  computer  as  centre  1 correct:-: 
will  he  used  to  ad  jus  1 tl  settln  ;s  f the  primary  contr  1 
values  of  the  process  in  order  tt  bring  th.o  vari.  ua  \ ■ 

va  ri ablf is  int<  Line  ' 1 ■ their  Jesired  /a  1 i c previ 
set  by  an  operator  or  by  sup1  rvis.  r;.'  n ntr  • c ■ 

This  may  be  acc  mplisl  : In  severs  1 ways.  S m<  f ti 
are  as  f c 11 ows : 

2. Cl  A d.c.  s i gr . ■ < 1 in  the  range  of  - ma  corresj 

to  standard  electronic  analog  contr  1 let  to  . ■)  ■ 

signals  would  bo  fed  tt  conventional  curre*  4 tt 
pressure  transducers  and  then  t<  st andard  pr  imati 
valve  actuators. 

.•r  A discrete  c ••  dl  jital  pulse  type  signal,  : 
of  pulses  to  represent  the  magnitude  of  th 
: \ v lved . Such  a > ys tei  w uld  us  a c t s : • 
rate  and  could  determine  pulse  number  by  c.  un'  he 
dowi  a ■ inary  counter  containing  the  contr 
va 1 uo . 

. • • A sing 1 discrete  r dig! ta 1 pulse  J ..a  e si 

whose  puls*  !«.»  ‘"t;  i’  pulse  heir'-’''  wtuld  • 
represent atl  ve  . f th*  ::n  ' turi.*  of  to  • *•.•*•  * 

1 mp.  r.t  d . 

...  I ( ' . > , !,•>,.  t I*  •(  ;•  • 1 *•••  ’ • O' 

r - ff  devi  • ■ . 
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Man.ua  1 backup 

As  mentioned  in  Item  2.  4,  it  is  imp<  rativ  thal  a i et 
for  manual  » peratic  i\  of  the  plant  1“'  provided  t al  ow 
fs  r continued  operation  of  the  plant  durii  ■ as  many  as 
possible  of  the  potential  computer  system  interruptions. 
It  should  have  the  follow  features: 

P.71  Automatic  switching  from  direct  computer  contr- 

to  a “locked”  condition  whenever  computer  r pul 
signal  failure  of  any  kind  ecurs.  This  "loc  i” 
condition  shall  preserve  the  last,  set  value 
control  output  s-  as  to  maintain  the  last  va  vo 
positi  >n  unti  1 reli 'a:-  3 : y ■ s ibsi squ  nl  mai  la 
jorrectloi  or  t :omputer  *etum3  ; ■ tr< 

f process.  ns ■ f<  :w  :as  s , e v: 

may  1 required  1 ; some  preset  "safe”  positi 

upon  c < . pu  ■ 'T  " ' 1 ’ ir  . 

. . A backup  ] re  r sup]  Li  pendenl  !*rom  tb  r f 

■ : . ripul  r • f : c pul  r ] ter 

inte rf< f re  wit  :omputer  or  manua  :ontr  ac  : 

■ porati  : . 

2.73  Ln  case  analog  utputs  ar  beii  used,  b:  ■ i] 

valve  control  device  c.  uld  be  a potent i .1  a v:h  r< 
p.  si ti  »n  and  hence  output  voltage  c uld  c rr-  ;;t 
t<  i ' ■' 1 valv<  air  signal.  It  would  l :orres]  j 
r-ughly  t valve  position. 

.7  r digit;  r pul!  itput  signals , an  "inchi 
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button  or  switch,  which  would  apply  a train  f 
pulses ts.  the  valve  motor  during  the  time  the 
switch  or  button  wore  engaged,  could  b-  out  i: 

A single  button  could  be  multiplexed  by  means  r 
a selector  switch. 

0.75  Some  method  of  rough  indication  of  v.lve 

positic>n  would  be  extremely  helpful  in  startup 
operation  of  the  unit  and  in  putting  the  computer 
"on  line"  for  control.  Such  a devic  :■ 4 p<  r 
from  a differential  transformer  on  the  valve  stei 
Any  other  suitable  method  of  indication  could  gi- 
be used. 

1.76  Some  method  f assuring  "bumpless"  tran:  fer  fr 
manual  to  computer  control  such  -is  a fast  r 
while  in  manual  position. 

.3  Systems  Tests 

In  order  to  assure  the  perator  of  the  continued  satis- 


fact 

ry  operation  of 

system  c. 

mponents  a seri 

os 
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t '•  ■ 
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period  it  shall  independent  y Lnltiat*  tl  • 
over  or  fail-safe  ..penil  n pr^S'-rih'-d  f r • : r • * 
mainframe  failure  ir.  the  syste.  . I'  : 

time  involved  will  r-  rnal  r 1"  f 1 r 

one  or  a few  seconds, 

2.82  Trial  Computati  no. 

the  system  will  havt  ine,  r]  r ' -d 

priority  f met 3 n a 

cedures  capable  r testing  • 

elements  and  storage  d vices  . that  • it  •. 

will  bo  run  continuously  during  all  •••  nt  ••  ... ■’ 

"idle"  time.  Fai  ir  btair  • " • rr 

answer  at  the  nclusiov.  if  any  one  f t !.■  *■  -t.: 

will  initiate  a repeat  of  this  test.  Fa3  ire  t 

succeed  after  three  of  those  repeats  will  initial 

the  prescribed  switchover  or  fail-safe  operational 

procedure . 

.8?  !2  sed  L<  p Test.  Each  separate  mu  tl|  exer  ur  it 

shall  have  ass  dated  with  it,  a "cl  sed  1 . p" 
system  which  will  accept  a signal  fr  m a field 
mounted  device  which  is  periodic^  y reset  by  tl 
computer  according  t-  a preset  pattern  which  is 
3 nit3 ated  in  turt  by  the  anal  g 3 lput  fr  1 ti 
f3  >ld.  Thus  a s<  If -perpetuating  loop  is  obtained. 
This  Last  shall  b<  associated  with  in  rr  r s 
devict  arid  a f 3 m<  r 3 such  a wa  / 1 1 ■ ‘a3  ur 
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to  obtain  the  correct  value  fr  :n  the  field  t 
accuracy  of  o.f'V'  or  tc  btain  such  a •••  lu 
a specified  period  cf  time  ( one  r a few  ■ • ndr 1 
will  initiate  an  alarm  at  the  operate  rr  alar’  ur  ' f 
( I tem  2.4) . 
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5 


DEC  IKED  MACHINE  C I iA  FACT  CHE '.TIC:' 

5.1  Machine  Aval  labili  ty  for  Continuous  Operation 

As  mentioned  earlier,  machine  avai Labi Llty  r time  act  la 
"on-line"  is  probably  a me  r<  Imp  rtant  :onsi  ! rat  ' 
reliability  per  se,  On-line  avai  abi  Lity  of  pr  is  t % : i - 
mizing  or  supervisory  control  computers  is  in  the  ran;:?  - f 
99 • tf/'  of  plant  on-stream  time.  Such  perf  rmanci  sti 
means  approximately  40  Ir  urs  per  year  d wntim  . Thin 
wi  uld  bo  entirely  unacceptable  where  plant  centra  111  ' 

entrusted  completely  to  the  computer. 

An  aval  labi  li ty  of  >9*9  f j ssible  j ant  n-stre 
or  bettor  (with  a resulting,  downtime  f h urs  r .• 
p r .year)  would  on  the  ether  hand  probably  h al  : . 

s w u d ■ e:  < :iallj  s if  the  auxilia  rj  levi  ( sep- 
rate  logger,  1 mdl  y mai  al  opera tiot  f faci  ities , 1 . ) 

previously  mentioned  ar"  available  in  I'!/-  ■ input"  r o/.y  n 

tr  all  w satis  fact  ry  standby  perati.  n burin,;  rep. a : r. 

As  a s m< intior  J earlier,  computer  d wi  time  musl  ' ■ id 

the  time  required  t.  d Eagres  a • achin'  failure  u 

n i]  ai  rs  t<  the  c<  mputer.  • ra]  uter  maintenanc 

cannot  be  coordinated  with  r y.ular  plant  off-n.  ' } ■ >-  - 

tional  procedures  must  b included  in  t oo  f.  ur  b ur  arly 

a 1 1 1 iwance.  Thus , east  " maintenance  c mbined  w ] 1 1 

well  planned  sot  of  diayn  otic  instruct!*  r.s  and  pr.  "dor  . 

for  the  maintenance  man  is  vitally  imp  rtant.  In  rder  J 

achieve  the  al  ve , a des' cable  e al  w uld  be  » t in  r<  than 
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one  machine  failure  per  year  (3 OOO  hours). 

• Read-out  f or  Trend  Recording  to  Accompany  the  Logging  ’ J ' 

Operation  of  a chemical  or  petroleum  plant  is  a very  'n- 
volved  procedure  during  which  the  operator  requires  a 
knowledge  of  the  plant's  present  status  and  its  1mm  -dj  a 
past  history.  Analog  "trend  recording"  cf  select--'  ’ 1 

variables  can  therefore  be  an  important  and  value 1 * 3. 

For  this  reason,  we  wish  to  consider  the  possibility 
providing  similar  recordings  with  the  control  s ye-  • >• 

discussion  here. 

. External  Priority  Interrupts 

When  used  in  conjunction  with  a large  optimising  r 
supervisory  control  computer,  the  direct  digital 
computer  should  have  the  ability  of  activating  the 
priority  interrupt  feature  of  the  large  machine.  • 

supervisory  control  machine  ci  uld  thus  take  correc  M ■-  • 
action  for  an  off -normal  situation  detected  by  tin 
control  c mputer. 

. 1 Aut;  miatic  Rondos  ti'uct  ■ ’ hut  down  of  Mem  ry 

Tt  is  imperative  that  means  bo  provided  to  insure  a '.ah  •’< 
the  possibility  of  destruction  of  the  pr  gram  r dat- 
menu  ry  locati  -ns  during  machine  shutdown  - r temp.  ry 
failure,  r i i the  event  < f external  power  failurr. 


W 
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V 1 p ry  I v i t o . qt 

Pr*  vi  sion  sha  1 be  mad* : i ■ • : rertaii  area  f mei 

(b  th  fast  mem<  ry  and  r ti  ting  bu  i * can 

by  hardware  operations  as  "protected”  I such 

one  cannot  read  inti,  these  .-.rear,  fn  m tl  *r  unp-1  te -t'  : 

areas.  Protection  may  be  by  single  words  t-  by 

The  system  should  be  able  tc  protect  up  t.  rc-h  i ' f r 

available  memory. 

Parity 

It  should  be  possible  to  perf.  rm  parity  t sts  n ■ 7 ] 
internal  and  external  transfers  if  date  thrcugl  ut  t: 
computer  and  the  data  system.  In  the  eve  ( of  a det*  :t<  d 
parity  err*  the  operati  r should  be  n<  tifi  id  by  J '■  - 
functions . f hut  down  or  transfer  should  net  be  initiated 
except  by  operator  request. 

FI.  ating  Point  Hardware 

The  wired-in  capability  f :arryln  ; out  fl  at  j ;-j 
arithmetic  and  r«  a ted  peratl  ns  should  be  prcvid 
all  Level  2 and  higher  d<  ;it;  I computers. 


1 


I 


- 156- 


JTHEF  PECHNICAL  CONSIDERATIONS  AND  DEFI  flTH  NS 


. 1 System  Grounds 


The  computer  vendor  must  detni  ] his  minimum  ream  r in 
for  a system  ground  or  grounds  for  the  computer  system 
fur  compatibility  with  the  rest  of  the  Inst rumen- c.-tl  m 
system. 


. c ' Terminal  B1  ocks 


The  instrumentation  systems  t,  bo  associate  •?  1 

each  direct  control  computer  will  normally  • .> 
stalled  in  such  a way  that  signals  from  'ml  ’ 
plant  units  will  be  made  available  to  tl  • : ’ > '■ 

at  a "terminal  block"  in  each  control  r • 
multiplexer  location.  The  vendor  will  then 
be  responsible  for  transferring  the  si  gnu 
the  terminal  block  to  and  through  his  supp 1 ‘ 
equipment.  Normally  this  c ntrol  r on  ’ t<  n it  •• 
block"  will  be  the  input  terminal  strip  n J , 
first  unit  of  the  computer  or  an  ei  nt-vi  ■ 
plexor. 


S i mllarly,  th<  ■ vend<  r wi  : 1 t m ally  b< 
for  transferrin*  the  computer  output  sf  •• 
as  far  as  tl . c \ itp  it  ' ra  : t • 1 • 1 ; ■ • f 
•f. ntrol  room  V rn:::.  to  jr.ul  tij  ’*>-*•  r 
< m nt  rc  ! si  i'l.al  s to  the  i ’ i 1 • rati  * ’’ 4 

this  output  t rm'nal  b ! » • • . 

,i!  t rut  to  tvnii ' • 1 ' • 1 r r 
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4.23  Figure  7 should  further  clarify  I tens  4..  • 

4.24  Venuor  should  present  his  recommendations  concerning 
pooolble  lead-in  wires,  etc.,  for  the  handling  of 
the  various  possible  input  signals  described  under 
Item  2.11. 

4.25  Any  signal  conditioning  equipment  required,  sue),  as 
dropping  resistors  in  current  systems,  must  be  supplied 
by  the  computer  vendors. 

4 . 3 System  Master  Clock 

In  order  to  Insure  coordination  of  system  operations,  a 
master  clock  should  bo  provided  if  not  already  present  in 
an  associated  optimizing  or  supervisory  control  computer. 

This  clock  should  oupply  the  signals  for  controlling 
sampling  rates,  logging  operations,  and  other  time  dependent 
system  functions. 

4.  4 Systems  ling  Inhering 

It  is  contemplated  at  present  that  user  companion  Installing 
direct  control  computers  will  carry  out  all  plant  systems 
engineering  and  computer  programming  other  than  wirod-ln 
functions  which  may  be  associated  with  the  installation  of 
a computer  of  the  type  discussed  herein.  The  vendor  is 
responsible  for  any  wired  programs  or  special  functions  to 
be  Included  in  the  computer. 

4 . 5 Technical  Data  on  Computers 

Computer  manufacturers  should  include  as  much  pertinent 
data  on  their  computer's  oupabill ties,  operating  character- 
istics, speeds,  etc.,  as  is  necessary  for  proper  evaluation 


A 
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of  the  proposed  machines.  Theuo  data  must  lnolude  at  loaot 
the  following: 

4.51  A full  discussion  of  machine  organization  and  method 
of  operation. 

4.52  Speed  of  operation  of  all  associated  Input  and  output 
equipment. 

4.53  Physical  sizes,  weights,  power  supply  needs,  required 
floor  space,  etc. 

4.54  Drift,  temperature  sensitivity,  frequency  response, 
and  oommon  mode  rejection  capabilities  of  system 
input  amplifiers. 

4.55  Complete  reliability  analysis. 

4.6  Thermocouple  Reference  Junction 

If  thermocouple  reference  Junction  units  are  to  be  provided 
by  the  computer  manufacturer  for  the  thermocouple  input b, 
they  Bhall  have  a temperature  stability  of  at  least  Z 0.2°F. 
Vendors  should  specify  the  number  of  thermocouples  whioh 
can  be  Included  in  each  reforenoo  unit. 

4 . 7 Environment  and  Klectrlc.nl  Cl  gasification 

4.71  ' 1 ' puters  will  n n . be  instal  ea  i ■ : r-< 

control  rooms  of  standard,  petroohemloai  plant  typo 
design.  The  atmosphere  in  those  oontrol  rooino  will 
be  relatively  good,  but  oannot  bo  maintained  completely 
free  of  dust  and  may,  at  tlmos,  be  subjoot  to  some 
small  amounts  of  hydrocarbon,  nulfurous,  ammonlacal 
or  halldo  vapors  (all  loss  than  5 ppm). 
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4.72  The  control  rooms  will  commonly  bo  prossurlzed  and 
be  classified  as  "general  purpose"  electrical  areas. 
However,  Individual  requirements  vary  and  should  be 
investigated.  A Hlvlslon  2 classification  is  generally 
the  most  severe  required. 

4.73  Vendor  should  specify  any  environmental  limits  required 
for  tho  machine  such  as  maximum  and  minimum  allowable 
ambient  temperatures,  humidity  ranges,  eto.  A doslrable 
temperature  range  would  be  to  be  operable  from 
50-110°P.  with  no  damage  to  130°F. 

4.74  In  some  eases,  plant  control  rooms  may  oontaln  small 
amounts  of  hygroscopic  dusts.  For  ouch  specific 
situations,  troplcallzatlon  of  tho  olootronio  equip- 
ment would  bo  very  desirable.  In  addition,  an  open 
type  configuration  of  the  equipment  uuoh  ao  required 
for  easy  maintenance  (item  1.213)  would  bo  quite 
helpful  for  cleaning  of  this  equipment  of  deposits 
whioh  may  form  from  hygrooooplo  dusts. 

.7  ■ te  multi]  :x<  rs  wi  1 t normally  b 

air-conditioned  and  pressuri  nod  area::. 
these  must  be.'  protected  by  micL  sums  or  ' r 
devices  capable  i f pr.  vidir  . ■ n c r.r.ary  p •*  1 • * 

f'r<  m p''  ant  : • a r.  ’ uri  • , n x:i;  us  vap  d 


‘ield  data  and  c 

it  " • ■ ' nsiea3  /■safe”  s f < :tri  ; 

voltage  and  curr.  v t < r p.  wc  r a.-  pr-.;yi-ril»“<l  \.y 
appr< priate  standards. 
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■ . EEDS  DIRECT  CONTI 
. . i . ystem  Ctr.o 
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Remote  multiple.'lng  f plant  signals  should  reduce  . roat  :y 
the  pro!  ems  r systei  nois  r<  ; i since  hi gl 

level  digital  signa 1 wi  1 n-  rmally  be  carried  ir 
' ■ ; ■ . v;  , rs  ust  continue  usu? 

wirit  g i racl  ices  in  btaining  analog  sign?  . E“r 
field  and  carrying  th-m  t.  the  nearest  field  mounted 
mu  t i r Lexer.  Us  ■ f twisted , shielded  le?  Is , f pr 
Line  ba  :ing,  and  ; < 3 grout  3 in;  pr  ; t ice  t j . t 
investigated  and  used  wh  re  apj  r j riate. 


En  ad  iti  n it  is  n cessary  tha  n ise  r ti  t :ap- 
ab  3 L3  f ■ mu  ij  ;xer  data -input  :t3 

■ 1 1 i ■ 1 y high.  Pherefore,  it  is  r<  iu  . t • t 1 

input  data  s<  • 1 3 ha\ e at  ast  the  f wi  . • ter- 

isitics : 

Ability  t reject  j to  . . n mode 

at  t iyc  s AC  wh<  imj  c ros  t 

DC  ' ' ' ' ' ' i ■ : ■ Lt 3 . ■ if t 

r less.  There  s lamag 

as  hig]  u - ts  ar  apj  ' i. 


pling 
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initiation  by  a single  si  pa;  fr  m tl  systei 
timing  device,  N rand  n sampling  capabi 


be 

provided . 

Ove rail 

sampling  speeds 

and  ana 

to 

digital  c 

; rivers i.  n 

speeds  must  be 

fast  en 

so 

that  all 

varial  les 

are  sampled  at 

the  spec 

needed  f:  r the  fastest  v.  sp>,ns-.  luncti 
system. 

6 . J>  Direct  Memc  ry  Access 

T;  prevent  the  required  fast  sampling  speed 
It< si  t . fr  m ■ ve rloading  tl  computation; 
facilities  <.  f the  system,  Q 1 computers  sh 
have  direct-meim  ry-access  devices  t-  pevnii  •• 
of  input  values  directly  inti  memory  rath  r 
through  the  arithmetic  unit. 
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FTWA.I-  !■:  CQHCIDKBATUu,: 

HA' II) LT MG  OF  FRCChA'  I/O  BY  'HfC  COMFUTATIOIIAT.  UT.TT 
7 . 1 Pr.  cess  Measurement  Inputs 

7.11  Scheduled  .'can;  It  sh  tic  be  ; ssib  ■ t sp  if  y 
an  internal  computer  scan  frequency  < r pr  cessing 
interval  for  each  input.  Completely  rand,  m 
specification  of  frequency  will  not  be  necessary  if 
enough  different  time  classes  are  included. 

It  should  be  possible  to  distribute  the  sc^e  : . 
of  the  inputs  in  a given  time  class  over  tee  peri.d 
of  the  time  class  si  that  the  c.cmputati  nal  fa..- 1 lit* 
re  not  overl  aded  t certain  times. 

For  example,  if  phas ing  were s ■ • { d ne  i sy  fcem 
containing  ( . 5,  , 5,  11  , ),  and  6o-sec  nd  tin 

classes,  they  would  all  come  due  every  minute, 
possibly  causing  t e scanner  t fa  1 • behind, 
however,  must  n t interfere  wil  ; above  gr  iping 
requirement. 

7.12  Validation:  The  input  value  of  each  ned  ' put 

should  be  checked  A r validity  Limits  and  or  il  ;a 

nf  i guro.ti  - n. 

:t  s'n  uld  b'-  p.  ib 3 e tc  rom<  v an  input  f r r. 

int  .-val  c mput  >r  scan,  r limit  checkin  ' wi 
ias  fa j ■ a 1 j J i . Lmits  for  t consecutj  1 : i 
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where  n is  a system  generation  parameter. 

It  should  be  possible  to  output  a message  v'ti.  t'  ■ 
out-of -limit  value  when  a point  has  failed  vali  yy 
limits  n consective  times. 

7.1?  Conversion: 

7.131  Compensation:  input  readings  should  bo 

compensated  for  zero  offset  before  applying  <0;  - 
version  equations. 

7.132  Standard  equations:  Provisi  n should  be 

made  for  several  different  conversion  equal; ' : . 

for  example 

(l)  Thermocouples  including  the  following: 

Iron-Constantan 
Coppor-Oonstantan 
Chrome 1-C ons tantan 
Chromel -Alumel 

Platium  - Platinum  Kh.  dium  ( 10'/  ) 

Platinum  - P 1 atinum  Kh.  dium  (!'%'> 

Conversion  ei  -efficients  sh  uld  be  suppl  i 
will  provide  errors  within  the  limit. s if 
Standard  C96.I.  Input  readings  si  .uld  : 


f..r  therm,  a . >uple  reference  !>•  T.  re  • onv-'-rs  1 . 
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F 3 v iw  coj tv<  • rs i n LnCi  rj  ratii  * a squan 
root  funeti  n 

a.  Liquid  I 'lew: 

Uncompensated 
Temperature  0.  mpensated 
Gravity  C mpensated 
Temperature  and  Gravity  ' ;-.p 

b.  Gas  and  Steam  Flew 

Uncompensated 
Pressure  C\ mpensated 
Temperature  C< 'mpensated 
Gravity  C-.  mpensated 
Combination  cf  above 


7. in- 


spects] equations:  user  should  have  f 

ability  to  specify  any  ther  con vers i n,  such 
as  table  look -up  for  code  conversions,  and 
to  relate  scan  frequency  t-.  filter  and/  r 
c • ■ ;rsi  1 proces  Li  ; i i f 1 rval  uj  t< 


: e r 1 

a in  p] 

a letermined  i 

( 1 ! ri  ng: 

Each 

input  si  uld  have  t e 

; pti  on  if 

having 

its 

va  lue 

filtered  using  a di 

hit 

liter 

factor 

spec 

i fled 

on  a point-by-point 

ba 

user  s' 

u u 1 d 

have 

the  abi  1 3 ty  t.  spaa 

ify 

any  fill: 

equati 

ns , 

and  ir 

y filter  processing 

in 

rva  . 

Ala  r:a ; • 

"*  fT  • 

input  s'  a u Id  have  the  pt.J  , *.  f 1 avi : 
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its  value  checked  against  h th  M.;rh  an  ' 

limits  and  a rat-  . f char..'''  . Wh 

Vi  1 -i  t ' ns  ccur  it  si  i 1 possl 

( 1 ) print  a message 

(2)  cause  the  executi  n f • pv  grot: 

(3)  open  or  close  a c n.tact  (us  r : 
the  ability  t-  sp  / ' ''y  t 

(4)  any  c-  mbinativ  n f the  v 

Process  Outputs 

7.21  of  the  twc  common  let  ma  rms  f utj 
( abs . lute  and  increment?  L)  th<  ii  ;rem<  t- 
is  preferred. 

V..  . Output  Generati  n;  The  get  rati  • it| 

s' i uld  allow  for  demand  utputs  r the  sp-  • 
f frequency  and  phasing  T ■ output. 

7 .23  D< vl atl  n Limits : 1 • ;v i a J i ns  ar  d fin  d • 

difference  between  the  current  utput  valu- 
1 . 1 1 ■ ru ‘w Ly  calculated  utpul  value . Ma  ' u 
de via t may  03  : nal  y I ;p<  ■ i f j f r 

. utpul  wl  i c h ar  t.h<  Limiting  va  tes  ‘at 
n an  -utput. 

T f the  dev_  U n limit  is,  ,'dod,  ••  pr 
linkage  (..  a -p-  o ; r;  -,ri  r"',-gt"i::  t an  he  -s‘ 

- a(3_ba  d t-apabi  Lty  5 1 1 : I pr  vid 
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7 . Event -Or ionted  Input 

Interrupts  should  be  caused  by  changes  ir  state  , f si:..' 
bit  inputs  from  one  logical  condition  tc  the  ther,  • it 
not  the  reverse. 
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VAr: /COMPUTER  CCMMUrjICATIOrr.  RELATE!  TO  OPERATION  ART  ■ 

qy  THE  PIAHT 

■ ^ General 

A response  should  be  given  to  the  requester  to  i.ic ' -a  to 
either  a valid  or  Invalid  request  was  made.  If  an  inv 
request  has  been  made,  the  system  should  indicat' 
reason  f.  r trouble. 

• Process  op ora ter  and/or  Supervision 

8.21  Active  entry  functions: 

Fhese  operations  should  he  aval  Lai  1 :hat 

operating  status  of  th"  system.  To  is 
of  the  operator  entry  functions  should  b 
such  a way  as  to  require  his  performing  cro: 
additional  coded  (keyed)  actions  sc  as  t 

the  possibility  of  inadvertent  entry  . f ■ 

information.  A13  parameters  availal  le  ! 
operator  should  have  a range  .f  acceptab.1  > vHvo 
and  the  operator  should  be  n.  t if  led  wh^r  hi  o o'  rv 
is  not  within  the  acceptable  range. 


’ 1 ] 

Alarn  Scai  : 

The 

operate  r sin  ui  d 

(1) 

Activate  < !’ 

tivat 

(■) 

Change  tl 

' 

and  1 w alarm  ; i 

(■■) 

.......  ; . , 

rat>  - 

- ■ ■ imits 
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>.2i;  L ;gin  •:  ■ o]  erat  ■ r sh  u d be 

to: 

(l)  Add/deleto  a variable  t,/f n r.  a 
( Request  1 >gs  on  a timed  frequency  r 
demand . Thi s includes  Jesignatioi 
an  interval. 

3.213  Trend  recording:  The  operator  sh  u d l 

allowed  t;  specify  the  pen  number  and  variable 
along  with  the  desired  frequency,  the  desired 
and  intercept, 

• ■ r Contr<  1:  Those  parait  iters  wl  icl  r iuire 

knowledge  of  control  the*  ry  and  tin; in/,  should 
be  considered  as  oj  >rator  functi  >ns . 
should  be  a.  1 w^d  t . : 

(!)  'h-  ago  the  set  p.  int  * f a 1-ip. 

(?)  Activate'  i r deactive  a loop, 

inland  unctions:  Certain  functions,  includj 

use  r ap]  Lcati  n p r 'rams , s ould  made  aval 
to  thi  j *at  ■ and , » s l uld 

•apabi  1 i ty  to  : 

(l)  .'elect  thf  functions 
i ) Specify  . ' ■ ' f I • ; ' ■ for 
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9 . 3 

9.31  • -v 

- ••  ‘ of  cy  ■ ■>  •> lit.  : • «- ng  ailu  as — 

tvai!  b ioi  .•  por  *y  s<  requ<  tors. 

. . .r . . Cf  — a . . . * . 1 o > i .i j 'i c c a r o n. . * . oO  a r o ■■ 

til  ; priorj  . . h n r;  /;■.  s In  ; core,  the  re- 
gie. n r • . .hie  ..pecify: 

a.  amount  cf  . .:..v  ry  needed 

b.  priority  cf  .'coyest  for  memory 

-lie  v ye raxing  . y.  h....  should  then  satisfy  re-;.. 
i\  r memory  alloc  .lion  according  to  the  requesting 
priority. 

llocatable  me;  ry  may  be  partitioned  according  t< 
program  priorixios  and  high  priority  memory  would 
not  ho  availabl;  to  lower  priority  requestor;  . 

The  actual  iim  ns ions  of  p art! ti < ns  would  b< 
installation  parameters  and  should  be  done  in 
such  a way  is  t .....  memory  availabl  - t<  sati:  fy 
....  ; . c ' ( ( * . 1 ......  riorxtji  re  ne  t or s _.  md 

In t a in  . ne  . . ■ . - . . <. . 1 , .'  .. 1 tv  . . ....  . l.  ' 

scheme . 


9. 


JL  Li  . . a L-.  L.  _..  d GO  \ i."l  O O i tu  ti  OL^C.  til  a Li  i 1 L • ;UC  i ' \j  C '1  i'l  ; li  11  I . . 

I < i t ble  . . mory,  . Lnc<  th< i oper  ng  sysl  :an- 
sense  when  rc  lestor  Is  finished  It. 


need  dev 

rity  pr  - . Loc 


I 
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••■■.v  :/ 


9.43 
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roc  e 


(Level  and  higher  systems) 
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MICROCOPY  RESOLUTION  USl  (HART 

NAIIONAl  l-HKIAi.  I 'AM  ••!•'!  ••  A 
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I A ' ' t 


10.31  Ti  re  should  b t ic  ability  tc  generate  object 

coding  with  appropriate  "heador"  ini'  or  ma  t i on  so 
ci*av  ien u-^y  s . . e cc g c oc g can  o e . 

10.311  Loaded  in  core  .as  compiled  v.'ith  minimal  in- 
s c rue  t a cn  i r cm  v~>  Leader; 

10.312  Loaded  in  next  available  core  ( considering  pag 
odd,  even,  etc.); 

10.313  Loaded  in  core  after  a halt  pending  an  on- 
line origin  directive; 

10.314  Loaded  in  object-image  onto  secondary  memory 
as  directed  in  header; 

10.315  Loaded  as  in  10.314  except  in  "next  available 
segment"  of  secondary  memory; 

10.316  Loaded  as  in  10.314  except  after  a halt  pending 
an  on-line  origin  directive. 

10.32  There  should  be  the  ability  to  copy: 

i 

10.321  Relocatable  program  images  from  secondary 

memory  into  reloadable  form  on  compatible  in- 
put media; 

secondary  memory  into  reloaaa 
. input  media. 

•ions  to  reload  previously 
dumped  relocatable  program  images  and  data  images 
into  secondary  memory  beginning  at  specified 
starting  locations. 


ta  images 

I X1  O',  a ; 

'I’lTi  Oi*  COl'o. 

)L\  C 0 -J 

should  be 

provi 

relocate'. 

ile  pr 
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10.5 


Vi:  v. 

. ■ 1 * < .* } * go  » > i ’ i - u:  Ut'.\ 

I.um  flex  lb: 

: : : ty  t<  ■ 

pro- 

ho  ,;v:;h  be  alj 

Lowed  to  c: 

IOC. . ► 0 1# ! 1.U  l 

• • 1 i V ( ^ _,o 

bu7  7* 

h U-  bCli  GO  .1  wdt  ih  J lo  ’ 

'.0  task  to 

bo  pori’i  *:r.( 

'0.  He 

should  1c  permitted  to  intermix  these  language 
at  at:  .viuts  within  one  program. 

.10.51  inolistih  nl  Process  Language  to  Assembler; 

10.52  Industrial  Process  Language  to  Problem  Oriented 
Languages ; 

10.53  The  Industrial  Process  Language  Compiler  should 
tolerate  "Foreign"  statements  in  the  above  languages 
and  permit  the  Assembler  and  other  Compiler  to  an- 


alyse these  for  correctness,  etc. 


10.6  Areas  of  Tr.-nroven.ent 

10. 6 1 Creator  modularity  of  software 

10.611  Operating  System  Software 

10.612  Other  Packaged  Software 

The  vendor  documentation  of  these  packages  should 
be  adequate  for  determining  how  to  remove  task 
modules  and  associated  subroutines  which  the  user 


may  not  require  in  his  system. 

10.62  There  should  be  a two-way-entry  method  of  determining 
whether  a subroutine  can  be  dropped  from  the  lib- 
rary, i.e.,  by  subroutine,  what  tasks  use  it,  and 
by  task,  what  subroutines  are  used. 
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required  for  a:. .ill 
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or,  1: 

systcii*#  .1  iic; 

larcer  system  may  be  located  locally,  or  remote 
from  the  object  machine,  ana  may  be  of  a different 
make  or  model  from  the  object  machine. 
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' ‘TROL  COMFJTATTOrC 

As  an  example  of  the  use  to  which  the  computer  may  be  put, 
it  might  be  programmed  to  simulate  functions  equivalent  t 
i • r f-m  <3e  controllers  having  proportional,  derivative  and  r set 
acti  ns.  Providi  n should  als<  be  made  in  this  ease  for  a sraa 
pn  p..  rtion  of  the  controllers  tc  operate  in  cascade  as  described 
i ::  the  following  subsections.  In  addition  to  the  example  bel  ow, 
it  should  be  kept  in  mind  that  ether  more  eleborate  algorithms 
and  mere  complex  control  functions  will  be  required  f these 
machines.  Such  functions  will  probably  not  involve  more  thar 
twice  the  memory  and  computational  requirements  outlined  . 


The  basic  controller  equation,  if  a position  alg  ritiim 
is  being  used,  might  be: 

Output  = Kp  e + b KRe  + Kp( en  - , ) + K] 

where  K , KR  and  are  the  proporti  nal,  integral,  -nd 
derivative  gains  respectively.  The  err  r,  e,  r uld  b> 
calculated  as: 


= + (Set  p-  int  - Controlled  Variable) 

11  opt!  n < f using  < ither  a plus  r ntnu!  si©  It 
'rr.  r cal  :ulation  should  be  provi  d"d  f r nr 
c ntr  ] i . op.  An  adjustabl<  midrange  c nstant , • 
in  uld  be  included  to  provide  for  the  possibility 


■ t pr  p<  rtlonal  acti • n only  (i.e.,  K. , , * 0)  mlg  i 

b desired,  ro . value  of  K-,  should  b sucl  that;  if  t • • 


it 


and 


wore  .cr. 


th< 


output  would  be  mid'".:  . ■ . 
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The  summation  shown  in  the  controller  calculation  atx  v- 

should  bo  taken  over  all  previous  iterations  hence 

the  current  value  of  must  be  stored  between  itera 

K 

tions.  Proper  computation  facts  should  be  built  into 
the  controller  calculations  to  prevent  reset--  windup 
in  either  direction. 

Should  a velocity  algorithm  be  desired,  the  basic  con- 
troller equation  becomes 

Output  = [Kp/At]  (en  - en_1)  + (Kp/TR)en 
+ ‘ en-2^ 

Here  the  output  is  a velocity  signal  which  is  trans- 
mitted to  the  value  movement  mechanism.  Symbols  are 
as  follows: 

At,  sampling  interval  for  the  variable  in 
question.  (See  Item  2. it), 
n,  relates  to  last  sample  obtained. 
n-1,  relates  to  next  to  last  sample  obtained. 

T„ , reset  control  constant  such  that 

n 

Tr , derivative  control  constant  such  that 
" KD 

Note  that  the  midrange  constant  is  not  required. 

The  position  algorithms  would  be  used  for  an  ana  1 . g 
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blocks  . 

12.41  libraries  control  algorithms,  limit  check 
algorithms,  filter  algorithms  and  output  al- 
gorithms should  be  provided. 

12.42  incremental  control  algorithms  should  be 
available . 

12,45  the  user  should  have  the  ability  to  construct 

algorithms  beyond  these  supplied  with  the  cyst  '". 

12 . 5 Data  Base 

A structured  file  should  be  provided  for  specifica- 
tion or  storage  of  control  loop  information  such  as: 

12.51  input  variables 

12.5?  messages 

12.55  constants 

12.54  control  loop  cascading  specifications  such 
that : 

1.  the  operator  may  connect  or  disconnect 
cascade  at  any  level 

2.  it  should  be  possible  to  connect  -r  dis- 
connect cascade  on  request  from  a higher 
1 evel 

5.  should  the  intermediate  level  of  cascade 
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be  disconnected , higher  levels  may  op- 
tionally be  disconnected  as  well 

A means  of  easily  accessing  and  modifying  informati 
in  the  file  should  be  provided  through  the  '.porator 1 
I/O  devices,  the  system  I/O  devices  and  high  level  p 


grams . 
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13.12  Parallel  system.. , horizontally  organizes,  '.•.'ill 
cor..; lot  oi'  cither  "mothers”  or  "daughters". 
Kit'.,  a pure  xinatcly  equal  dynamic  requirements. 


13.21  System  into. may  la  of  primary  importance  so 
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failures  throughout  the  hierarchy,  local 
P o /. o r a „ . — lux  e..  * c uSGr  j.  ailares  ,TiX  o he  .iv.  oec 

by  a« joining  elements , even  though  normal  ciara 
cc...,.un lection.:.  (or  control  of  communications) 
ray  he  one-v;:  y. 


13.22 


System  genera  v.l on  . ..mode  vah  he  us *0 o to 

structure  the  hierarchy,  to  determine  the  source 


-203- 


13  .23 


t<-  .-'J-r,:  -i 


13.24 


13.3 


i o'.'  ^ . 


m.  d./secim-  and  r. re vented . 
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1.3.41  'fho  same  genera  1 procedures  are  to  be  used, 

whether  the  computers  are  local  or  remote  from 
each  ether.  System  generation  should  accommo- 
date timii. ; restrictions  duo  to  distance  ana 


sion  modes  lor  each  channel  used. 
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L,v-  ^ ■ g - tno  opera  y j.iij  „y.  uCi.i 


•:  ■ causing  their  creation  by  means  of 


h.ter.ance 
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bae  i ol lowing  items  snculd  be  available  as  defining 
* i-  lyOi'u  r ci'j!,  u y.oi'.  Ci  i r lo  s : 

La ber : either  a number  or  character  string. 

,12  Device  on  which  the  file  will  exist 
,13  Type  cf  file: 

( 1 ) 0 rga n i ::  a t i c n : 

Sequential  access,  or 
Rand  or.  acess 

(2)  Record  type: 

Fixed  length,  or 
Variable  length 

(3)  File  type: 

Fixed  length,  or 
Dynamic a lay  expandable 


File  Sice 

(l)  number  of  records  for  a fixed  length,  or 
(•  ) ini t tax  nun... er  of  records,  plus  incren.  -nt  .1 
nuiv.be r of  records,  plus  maximum  allowable 
number  of  e.  ions  (increments)  for  uyr.mi.ie-  liy 
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..  • V.  . 

14.15  fisc 

( l)  number  vi*  worw; /characters  per  record,  for 
l ixcu  lc nc  j t.i  f oy 

maximum  allowable  number  of  words/characterc , 
for  variable  length  records, 

( i ) i> I*  'C  sang  ~ actor 

14. 16  File  integrity 

(l)  Dynamic:.!':’/  definable  protection  via  "open" 

and  "clcse"  types  of  executable  statements  of 
application  programs. 

(a)  "Open"  file,  with  the  following  item. 


* i i »->  cl  •- 


File  name  or  number 
Definition  of  status  as: 

Reserved  for  exclusive  use  of 
"opening"  program.  (puts  file  into 
"protected"  status  for  all  other 
programs) 

"’■.'RITE"  reserved  for  "opening" 
program  (places  file  into  "read-only" 
status  for  all  other  programs) 

Unlimited  access  for  any  program 
Error  return,  for  the  following  conditions: 
file  nonexistence 


Eo 


in  application  programs,  with  return  of  error  in- 
formation to  the  application  program  ( in  such  cases 
as:  file  non-existance,  attempted  access  of  a cl;  sed 

file,  attempted  write  to  a "read-only"  file,  access 
attempted  beyond  range  of  file,  and  attempted  access 
of  a "protected"  file); 

a.  "READ"  a logical  record  from  the  file  int,  a 
variable  or  list  of  variables  specified  in  the 
statement.  (Subject  to  file  integrity  specfica- 
tions) 

b.  "WRITE"  a logical  rec>  rd  from  a variable  or 
list  of  variables  specified  in  the  statements, 
to  a file.  (Subject  to  file  integrity 
specifications ) 
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APFKNPTX 

• UR  ITT  ONf  ANT*  ANf.WERD  ON 
PIGTTAI  COMPUTF.K  FA :’KD  INPUhTRIAL  OONTrKT 

is  par ; f t 1 < riglna  doe  im  rnts  of  the  Use rs  W rksh  p 
i'lrvct  Digital  computer  Control  Systems  hold  at  Princeton,  New 
Jersey,  on  April  7>-4,  1965  and  May  6-7,  p)6H  under  the  auspices  f 
f'i"  Chemical  and  Petroleum  Industries  Division  .•?  tl  Instrument. 

S(  sietj  f America,  a set  of  Questions  and  Answers  on  Direct  i 1 ;ital 
■ ittput  C 1 it  r ' wer  • develi  ped , The  fol  Lc  wing  is  a listing  wi 

comments  . f those  quest ions  and  answers  given  there  which  are  con- 
sidered t,.  remain  va  lid  as  of  this  date.  The  exact  wording  ■ f th- 
, riginal  questions  has  been  altered  somewhat  in  severs]  cases  to 
bring  the  questions  up-to-date  with  present  concepts  and  trends. 

It  should  be  noted  that  those  Questions  and  Answers  retained 
pertain  almost  exclusively  to  the  characteristics  . f the  plants 
being  0 ntrolled  or  tin-  desires  of  the  operators  f r data  presentation, 
etc.  Practically  all  of  those  related  to  the  computer  equipment 
itself  have  been  answered  since  by  the  accepted  practices  > f the 
industry  or  are  e vered  by  specific  items  in  the  proposed  new  Guide- 
; which  ace  : pany  this  document. 

)!i  I-,  with  t he  backgrounds  of  the  individuals  who  comprised 

• riglna  ' v;  rksh  pe  tru  st  of  these  quest ix^ns  relate  to  the  p ants 
. pr  • >ms  r ' t e .... j , ■ and  Petroleum  Industries.  Equival  nt 
Inf.  rmati.n  r.inu'd  be  developed  for  each  of  the  1 her  ma,j  r industries 
us!  , digit  ally  based  control  systems. 
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. IJM. :T]  i 1 --  What  valve  closing  speeds  are  required  for 
typical  chemical  and  petroleum  plant  applicati  ns? 

• s this  a function  of  line  size? 

If  s;  , what  is  a typical  distribute  n of  line  sizes  f.  r 
a large  chemical  or  petr.  leum  processing  p '.ant? 

.WV.i'CR  1 — Table  VII  gives  some  typical  data  f . r pneumatic  va  '•••• 
cl  sing  speeds  with  and  without  volume  b;  • -oters  and  t 
Tables  VIII  and  IX  give  some  Corresponding  data  f r r' 
actual  rs  and  positioners  manufactured  by  the  Fislvr  ' v •• 

C mpany,  Marshalltown,  Iowa.  Tables  VTII  and  IX  ar  ; ri 
f r. m Fisher’s  Bulletin  E-oOO,  dated  June  196 1 . Tab:  VTII 

is  from  Page  12  of  the  Bulletin.  Table  IX  is  from  P-  ■; 

It  is  th"  pinion  of  the  industry  gr.  up  that  the  str. king 
speeds  given  in  Column  5 of  Table  VII,  "Pneumatic  P.-oiti  n r"  , 
am  sufficiently  fast  to  cover  ver  8of  of  the  contr,  1 
applications  in  our  industry.  Those  given  in  Column  a 
f Table  VII,  "Kendall  3/8  Volume  Booster",  are  sufficiently 
fast  to  e ver  over  91/'  of  the  possible  control  applicati  ns. 
in  the  chemical  and  petroleum  industries. 

Of  the  remaining  five  percent,  three  percent  can  b--  read!  ’ y 
handled  by  quick  opening-quick  closing,  s.  Ion  icl-typ- 
valves.  The  remaining  lav-  percent  require  contr  1 acti  1 


STROKING  SPEED  IN  SECONDS  FOR  CONTROL  VALVES 
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PISTON  ACTUATORS 


SPECIFICATIONS 


4*HwHr 

i?#V* 

Of 

Cftkihr 

tlmttar, 

looltoo 

- »» 

nwmw 
Ant, 
V«|n- or o 
too  into 

r«kt  Ui 

Un. 

too  Vo. 

Itw 

•tea. 

I»lk« 

AwW<4lt 

I4««l  *W 44 

tUkrwwMa  Trorrak 

Mott  Twm,  ImIm 

K8&. 

• *»PV*» 
Peacs^*, 
f4l  141 

TH*J 

IvrrtT 

4b 

144 

lb 

H 

1100 

4.-— 

iico 

’A.b 

~~toc~ ' 

» 

«b 

14.1 

lb 

b 

iloc 

. 

itoo 

Vn-b 

i« 

46 

4b 

71JFI 

*:V.4 

% 

7600 

ISOS 

f/..tb 

I0f 

43 

** 

14.1 

I'M. 

b 

!30C 

»&oe 

M4-IVS 

IK 

40 

PA 

HI 

r/.4 

b 

MOC 

sons 

Mi* 

>oe 

47 

4M 

14.1 

*7k 

b 

l«0C 

7100 

7ft» 

’A  .1 

110 

44 

4b 

ll.tl 

*Vu 

b 

weo 

1400 

Mi* 

IK 

•0 

l»b 

114 

i 

i 

seoo 



SOX 

b-l  HI 

160 

14 

»'A 

43  t 

V 

i 

U00 

P4X70 

b-K<C 

V.-1  (>l 

>16 

IOC 

11 

1704 

i 

tV. 

IJOOC 



S7&50 

b-i  Hi 

100 

>79 

17 

1114 

i 

iy. 

IMCU(l) 

itceo 

b » H) 

40 

Minimum  Supply  Pressure  30  psi  for  all  sires. 

Instrument  Pressure  Ranges 3 to  13  psi, 

6 to  30  psi,  and  others  as  required. 

IVIIows  Pressure  Rating 30  psi. 

A high  pressure  bellows  is  available  for  pres 
surc-s  between  30  psi  and  90  psi 
Temperature  Limitation 173  F maximum 
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CONSTRUCTION  MATERIALS 


Cy 

Cylinder  and  Piston 
Piston  Rod  and  Extension. 
Cylinder  Seal  Bushings 

Seal  Rings  

Yoke  

Po.lt 

Base,  Cover,  and  Beam 
Bellows 

Relay  Body  

Relay  Noxzle 


Aluminum 

Stainless  Steel 
Brass 

Synthetic  Rubber 
High-Tensile  Iron 

Aluminum  Die  Casting 

Brass 

Zini  Die  Casting 
Stainless  Steel 


PERFORMANCE  DATA 

Air  Consumption  (Static)  20  scfh  with  ll>0  |>si 
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pt  tttvt  e lot  470  4< 
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supply  pressure. 

Hysteresis  (Maximum)  . 0.159*  of  total  stroke 

or  instrument  pressure  span 
Repeatability  0 03fi  of  total  s'lokt 

or  instrument  pressure  spin 
Resolution  Sensitivity  ('  0 lr/  of  instrument 

piessure  span 

Frequency  Roponse  See  Figure  1 2S 

U«iln«M  Strok1*?  Sp«*it 

(l#»«4  On  »uppty  p>«nuff  io4u«l#<t) 


1*  Aif  *4 **+  Urn 

M 

40 

40 

K> 

IM 

110 

» Ipf/fr^y  Frtw**#.  ppi 

too 

too 

too 

100 

100 

to 

r Ww 

44 

1X4 

14 

04 

0M 

a >i 

SfcoOny  lo*tl  IWiJllf  to  no*  npply  U Tfpot  471,  411,  411  vA*!** 


TABLE  DL 


t 


SERIES  3560  V/P  VALVE  POSITIONER 


Fifiva  T yp.  3S40  lahtmalit.  0»«  Ciwi 

Reverse  acting  positioners  operate  in  a similar  man- 
ner except  that  as  the  instrument  pressure  increases, 
the  diaphragm  case  pressure  is  decreased.  Conversely, 
a decreasing  instrument  pressure  causes  an  increase 
in  the  diaphragm  case  pressure. 

ADJUSTMENTS 

Valve  travel  is  easily  adjustable  for  any  travel  be- 
tween y4"  and  3'  (as  required  by  actuator  size)  by 
limply  moving  the  flapper  arm  along  the  beam.  The 
beam  is  labeled  to  indicate  that  movement  of  the  flap- 
per arm  away  from  the  cam  increases  the  valve  travel. 
The  relay  nozzle  is  adjustable  and  is  used  to  set  the 
starting  point  of  valve  travel  at  the  desired  value  of 
instrument  pressure  These  two  simple  adjustments 
make  the  Series  3360  readily  adaptable  for  split  range 
operation. 


o,  . — nm  ifvtk 


•4  Typ.  447  4..pk..ym  hI»I«i  o-«  iuw 


The  V/P  is  reversible  without  the  use  of  additional 
parts.  For  direct  action  (increasing  instrument  pres- 
sure increases  output  pressure),  the  flapper  arm  is  po- 
sitioned on  the  bellows  quadrant  of  the  beam.  For 
reverse  action  ( increasing  instrument  pressure  dr 
rreases  output  pressure),  the  flapper  ami  is  pit  ed  on 
he  opposite  Quadrant  of  the  beam 

SPECIFICATIONS 

Maximum  Supply  Pressure  30  psi 

Pressure  Rating  of  Bellows  33  psi 

Nozzle  Orifice  0.040"  diameter 

Fixed  Restriction  Orifice  0 018'  diameter 

Pressure  Gauge* 1^2*  diameter  weatherproof 

gauges  with  0 to  30  or  0 to 
60  psi  range 

Pressure  Connections  All  ! , ' NPT 

Dimensions  high  and  6'g"  wide 

(with  pressure  gauges) 

Available  Rang*  Spring** 

IlitriMit  Tmiin  Iny*  ftaetaf  (petal  Calar 

Pit  P*|.  Na.  Catfa 

I t»  l»  1.1(474  Ca4ml«m  rwt. 

into  ~ IJU*. 7W 

iprUfi  Ibr  •Ht«r  lattrvmaM  pritun  r«*g«i  will  to  available  M 

PERFORMANCE  DATA 

The  following  data  has  been  taken  from  tests  per 
formed  in  Fisher's  Research  Laboratory  on  Type  631 
diaphragm  actuators  equipped  with  a Type  3360  V/P 
The  instrument  pressure  range  was  3 to  13  psi  and  the 
supply  pressure  was  20  psi.  Actuator  socs  and  travels 
are  indicated  m the  tabulation. 
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ut  must  have  a cl  sing  speed  of  0.6  second  r Less  regard 
less  of  the  size  vilv  involved. 


Table  X presents  distributi  n data  for  the  range  f valv 
sizes  used  in  one  of  our  industry's  larger  c hemic a 3 p 


. thing  has  occurred  recently  in  the  design  . f plant  i-.nt 
syj  terns  or  in  the  deve  pm<  nt  of  new  c mponents  wl  ich  ] r 
1 appreciably  change  this  t a f r continu  us  pr  c ss  i 


N I ( Pr  >vi<  us  u<  ioi  5)  What  sh;  ud  ■ • tl  pr<  :isi 

■ n tants  K Ent  ;ral  Gain)  and  (Pr  p rti  na  Lain) 

I 

Item  2.6l,  : f the  Guidelines? 


Whal  Limits  or  range  of  variation  sh  uJd  be  plaeed  n I 
c o nst  a ri  t s ? 


Wh  should  set  and  adjust  these  constanl  t ? 


ANSWER  --  The  desired  range  and  precision  of  setting  of  the 
gains  of  the  control  modes  of  the  direct  digital  control 
computer  are  as  follows: 


PROPORTIONAL  - Settings  of  the  proportional  mode  on  con- 
ventional pneumatic  and  electronic  process  control  hardware 
generally  range  from  10  percent  proportional  band  to  pOO 
percent  proportional  band.  Those  few  which  are  outside 
th^s  range  (up  to  1000  percent)  can  be  handled  by  special 
programming  steps.  The  given  proportional  bands  correspond 
approximately  to  loop  gains  ranging  from  10.00  to  0.<?0. 


r 
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TABLE  X 

DISTRIBUTION  OF  VALVES  ACCORDINO  TO  LINE  SIZE 
PETROCHOOCAL  PLANT  APPLICATIONS 


Line  Size  In  Inches  Percentage 

3/4  22.3 

1 7-4 

1-1/2  21.1 

2 22. 1 

3 8.4 

4 6.4 

6 6.8 

8 3.1 

10  0.6 

12  0.8 

14  0.2 

18  0.4 

20  0.4 

100.  0 


V 
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In  making  settings  of  mode  gains,  resolution  in  making  the 
setting  itself  is  far  more  Important  than  the  actual  setting 
involved.  For  this  reason,  four  digit  adjustment  is  required 
on  the  computer.  Thus  a digital  adjustment  to  0. 01  would 
be  desirable. 

Approximately  90%  of  current  valve  applications  would  use 
the  10-500  percent  proportional  band  given  above.  Approximately 
10%  would  be  outside  this  range,  requiring  gains  to  1 percent 
proportional  band  in  one  extreme  or  up  to  1000  percent  in 
the  other. 

INTEGRAL  - Integral  or  reset  mode  gains  are  commonly  expressed 
as  the  amount  of  time  required  for  the  development  of  a 
correction  equivalent  to  a proportional  band  of  100%  or  a 
proportional  gain  of  1.0.  Such  times  commonly  range  from 
10  seconds  to  15  minutes.  Again,  those  few  which  are  outside 
this  range  (up  to  60  minutes)  can  be  handled  by  special 
programming.  Another  common  method  of  writing  these  gains 
is  to  give  the  number  of  times  an  integral  mode  correction, 
equivalent  in  size  to  the  proportional  band  mode  correction 
of  the  instrument,  is  generated  each  minute.  In  this 
representation  a reset  time  of  16  seconds  would  be  roughly 
equivalent  to  4 resets/minute;  0.1  re3ets/minute  would  give 
a reset  time  of  ten  minutes,  etc.  These  given  reset  times 
correspond  to  Integral  mode  gains  of  from  1.000  to  0.001. 


As  was  mentioned  under  proportional  above,  resolution  in 
making  the  setting  is  more  important  that  the  initial 
accuracy  of  making  the  setting.  A digital  adjustment  to 
0.001  would  be  very  desirable. 

Again  about  90%  of  the  applications  would  be  in  the  range 
Indicated.  Some  very  few  cases  may  require  reset  down  to 
1 second.  Approximately  10%  of  the  cases  will  require 
reset  times  of  from  15  minutes  to  60  minutes. 
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DERIVATIVE  - Derivative  or  rate  mode  of  control  was  not 
called  for  in  our  original  specification  and  we  at  this  time 
see  no  compelling  reason  to  include  it  in  the  example 
problem  there.  However,  the  consensus  of  the  Users  Group 
in  discussing  direct  digital  control  was  that  derivative 
control  would  be  called  for  in  up  to  20$  of  the  loops  to  be 
included  in  a system. 

To  avoid  the  problem  of  system  noise  Involved  in  determining 
a system  derivative  digitally,  an  analog  derivative  might  be 
used.  While  this  would  necessitate  two  separate  inputs  for 
the  variable,  they  may  be  necessary  for  smooth  control. 

The  magnitude  of  derivative  action  Imposed  In  a controller 
is  usually  expressed  as  a "rate  time"  or  the  difference 
between  the  time  required  to  complete  a given  correction  by 
proportional  action  alone  and  that  necessary  for  proportional 
plus  rate  control  taken  together.  This  number  expressed  In 
minutes  and  multiplied  by  the  proportional  gain  equals  the 
true  derivative  gain  of  a noninteracting  derivative  mode. 

Rate  times  normally  vary  between  ten  seconds  and  fifteen 
minutes.  Since  the  longer  times  are  used  only  with  small 
proportional  gain  systems,  this  results  In  equivalent 
derivative  gains  of  between  10  and  0.01.  Again,  a four 
digit  setting  capability  would  be  desirable  for  purposes 
of  resolution  as  mentioned  above. 


-221  - 


Since  these  concepts  are  foreign  to  the  usual  Interpretation 
of  gains  in  servo  loops  as  taught  to  electrical  engineering 
students,  the  following  references  are  given  for  further 
study  as  desired; 

1.  Eckman,  D.  P. , "Automatic  Process  Control",  John  Wiley 
and  Sons,  Inc.,  New  York,  New  York,  1958,  Chapter  3, 
pp.  59-77* 

2.  Holzbock,  W.  G. , "Automatic  Control:  Principles  and 

Practice",  Reinhold  Publishing  Corporation,  New  York, 

New  York,  1958,  Chapter  4,  pp.  25-60. 

3.  Tucker,  G.  K. , and  Wills,  G.  M. , "A  Simplified 
Technique  of  Control  Systems  Engineering",  Minneapolis- 
Honeywell  Regulator  Company,  Philadelphia,  Pennsylvania, 
1958,  Appendix  F. , pp.  235-256. 

The  adjustment  of  controller  mode  constants  in  chemical 
process  control  systems  is  a duty  which  is  permitted  of 
only  a very  few  individuals.  Normally,  only  the  plant 
instrument  engineer  or  the  lead  instrument  mechanics  are 
permitted  to  touch  these  settings.  Presumably  the  same 
restrictions  would  apply  In  the  case  of  direct  digital 
control  computers  since  tbe  same  problems  of  plant 
stability  would  exist  regardless  of  how  control  activation 
were  actually  initiated. 
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CON  l ( Previous  QUEST  It  N ; ■■)  --  A engineerii  - ml : requi  * 1 

on  any  digital  logs  which  might  bo  used  by  the  operat  f >• 
p ' ant  monitoring? 

Are  exact  temperatures  required  on  logs  cr  might  s me  simp 
representation  suffice  for  operator  use? 

INGWllR  • --  It  is  connfton  practice  in  the  process  industries  1 pre- 
sent flow  rates  and  vessel  levels  as  percentages  . f :■  : ••  1 

determined  maximum  value  on  recorder  charts  and  • -■ 

• ther  hand , because  f their  great  er  imj  •-  t plant  saf 

temperatures  and  pressures  are  usually  presented  as  thei  1 
values  in  degrees  Fahrenheit  and  pounds  per  f iuare  in  :1  r - 
spectively. 

In  rder  t;  facilitate  operator  f amil iarie.ati . >1  with  the  :w 
type  cf  control  system  which  w uld  be  invlved  with  d t >■■•  t 
digital  control,  it  is  highly  desirable  that  this  syot.i  m 
of  presentation  of  plant  data  be  preserved. 

The  statements  just  given  should  he  taken  as  a clarifi  •ati 
and  expansion  f Et< :m  1 . . ? 3 4 , and  f : • ■■■  . . , of  t 1 1 uncti 

Guidelines  on  Industrial  Cont  r>  1 0 mputer  Gysteir.s . 

1 1 should  be  noted  that  there  is  .a  share  difference 
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j ' n . ( Prev  i us  . U ST  I I 6)  --  ] 1 rd<  r t prevent  rei 

in  the  c.mputer  contr  >1  c.  -input -iti . :ns , sh.-uld  eny  ep-ei-, 
signals  be  provided  to  c.  ntr  1 the  r< -sot  ■•••  i cu  ’ e 1 2 > n, 
internal  testing  of  the  reset  calculation  be  su 


- unit 


u lc 


•i  i 


Lt!  a f * 


ANSWER  i --  Reset  windup  is  the  continued  buildup  f an  iutegrc 
• ntrc 1 correct!  n while  the  c >ntroller  is  receiving  an 


input  error  but  is  not  making  an  actual  correction  of  the 
error  source  (as  when  the  controller  is  in  an  open-loop 
configuration).  This  can  be  a very  annoying  and  trouble- 
some condition  during  plant  startup,  when  taking  control 
loops  off  and  on-line  such  as  for  repairs  or  replacement, 
when  a severe  upset  occurs  In  the  process,  or  during  the 
operation  of  batch  processes.  It  can  be  controlled  or 
corrected  In  several  ways.  Among  these  are: 

1.  Establish  a maximum  limit  which  the  controller 
output  can  assume,  i.e.,  allow  the  integral  oontrol 
mode  to  wind  up  to  only  a relatively  small  value. 

2.  When  windup  occurs,  adjust  the  process  loop  set 
point  to  such  a value  that  a large  error  of  the 
opposite  sign  is  sensed  by  the  controller  thus 
Integrating  out  the  windup  signal. 

J>.  Whenever  putting  a control  loop  on  or  off  line 


set  the  value  of  all  integral  mode  outputs  to 
zero  and  require  a recomputation  of  any  neoessary 
integral  correction. 


-224- 


4.  Whenever  putting  a control  loop  on  or  ofi  line, 
make  momentary  use  of  a very  large  Integral 
constant  to  cause  the  Integral  control  loop 
output  to  quickly  assume  its  correct  value. 
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Item  .'.6 1,  f the  Guidelines  requires  that  fad  re  be  Id1 
inti  tlx • control  computations  to  prevent  roe et -windup. 

1 imit ing  method  discussed  under  F.  Fit  1 w u d tv  t’v  ■ ’ 

ace op table  solution  t the  problem. 

tinned  in  Item  . 1 < , f t reset  of  I 

may  be  ompl  yd  with  l tie  manual  back-up  e,yst' an  t ••  v’d 
u ;■•••< ! just  pri . r t putt  inf;  alp  • 1 ine  and  F 
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he  pr  cess.  II  : s estimated  that  the  re  t-vn  d i]  wi  1 
pr  hlem  in  ; 0$  f the  eases  whi  re  th<  res<  t ••  ntrc  n d is 
used . 


ST I ; : (Previous  QUESTION  °)  --  Item  ■ f the  Guidelines  ca 

f v at  on-stream  availability  of  99*95$  ■ f plant  op«  ratir 
time.  How  does  this  translate  into  mean- time -between-f a ilur - 
and  allowed  down-time  at  failure? 

Just  what  items  of  plant  and  control  equipment  must  he 
Included  in  the  system  for  which  the  availability  above 
is  to  be  determined?  If  such  high  reliabilities  and 
availabilities  can  be  obtained,  what  can  be  done  about  main- 
taining plant  operator  and  computer  maintenance  personnel 
proficiency? 

--  Extremely  high  availabilities  f computer  e nt  r i 
mipment  are  necessary  to  prevent  frequent  and  costly 
»hutd  wns  of  chemical  p ants.  One  unscheduled  shutdowr 
f the  plant  can  cost  the  process  company  in  .1  st  pr.  - 
dueti.n  many  times  any  potential  capital  or  operating 
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savings  which  the  computer  can  give  over  conventional 
control  systems.  Therefore,  such  shutdowns  must  be 
reduced  to  an  absolute  minimum  if  these  new  control 
systems  are  to  be  accepted  generally  throughout  the 
process  industries. 

Figure  12  represents  a p ssible  compr  mise  between 

mean  time  of  failure  and  system  downtime  which  would 
be  acceptable  to  us.  It  Is  the  consensus  of  opinion 
of  our  people  that  availability  13  unquestionably 

the  goal  which  we  all  desire. 

Parts  of  the  system  to  be  included  in  assessing  availability 
or  reliability  are  as  given  below.  These  are  essentially 
all  of  those  items  whose  failure  could  result  in  an  inter- 
ruption of  operation  of  a large  portion  of  the  control 
hardware,  i.e.,  up  to  1/4  or  1/3  of  the  total  number  of 
conti'ol  points  or  greater. 

1.  Computer  Mainframe  and  Associated  Parts. 

2.  Input  Multiplexer  and  Associated  Circuitry. 

3.  Analog  to  Digital  Converter  If  Multiplexed. 

4.  Output  Multiplexer  and  Associated  Circuitry, 
p.  Digital  to  Analog  Converter  if  Multiplexed. 

6.  Alarm  Detection,  Indication,  and  Printout 

Devices  If  Common  to  a Large  Portion  of  the  System. 


' 

i 

i 

i 

1 1 

— ^ 
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•ATI0N3HIP  OF  KEAN  TIKE  BETWEEN  FAILURES  AND  ALLOWABLE 
REPAIR  TIME  FOR  nTRECT  DIGITAL  CONTROL  COMPUTERS 
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Those  items  which  definitely  would  not  be  included  in  the 
equipment  whose  availability  is  being  judged  would  be 
the  following.  Again,  these  are  those  items  normally 
involved  with  the  operation  of  only  a single  control  loop 
and  those  items  whose  failure  would  :•  f fee  only  that  loop: 

i.  Individual  transducer... 

2 Individual  transmitters . 

j>.  individual  valves  or  valve  actuators. 

4.  Individual  alarm  Indicators  used  for  signal  of 

only  one  or  a small  number  of  points. 

It  should  be  noted  also  that  the  extremely  repetitive  nature 
of  the  operation  of  a direct  control  computer  would  make 
'dropped  bit"  errors  essentially  negligible  In  their 
effect  upon  plant  control.  This  is  especially  true  for 
the  integral  mode  of  control.  Such  errors  would  thus  be 
considered  in  figuring  reliability  only  when  they  begin  to 
occur  so  frequently  as  to  i mi  air  control  accuracy 

Maintenance  of  competence  on  the  part  of  operating  and 
repair  personnel  is  a very  serious  problem.  This  is 
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for  training.  Such  training  would  include  manual  control 
of  plant  changes  and  could  Include  preventive  maintenance 
of  the  computer.  Such  periods  would  not  be  charged 
against  system  availability  records. 

QUESTION  (Previ  us  UESTION  ) --  What  time  perl  <3  is  ■ 
required  for  a safe  crash  shut-down  of  a chemical  p ■<  ' . 

What  is  the  philosophy  of  shut-down  vs.  stagger  along 
operation  in  event  of  direct  control  computer  failure? 

What  type  of  units  would  we  want  to  shut-down? 

'What  type  of  units  would  we  want  to  keep  going? 

ANSWER  f --  Required  shut  down  periods  for  chemical  plants  will 
vary  greatly  depending  upon  the  type  of  unit  Involved  and 
the  possibility  of  damage  to  plant  units  due  to  thermal  and 
mechanical  stresses  and  corrosion  or  the  possibility  of  the 
danger  of  explosive  conditions  existing. 

Particularly  sensitive  are  furnaces,  fired  reboilers,  and 
other  3uch  units  which  must  have  their  temperatures 
reduced  slowly  to  prevent  thermal  cracking  of  firewalls, 
etc.  Equally  sensitive  but  for  the  opposite  reason  are 
refrigerated  condensers,  etc. , of  low  temperature  columns. 
Here  temperatures  must  be  raised  slowly  to  prevent  undue 
mechanical  and  thermal  stresses.  A period  of  several 
hours  to  days  may  be  required  especially  for  the  furnaces. 
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Another  area  requiring  care  Is  the  Handling  of  materials 
susceptible  to  polymerization  or  decomposition  when  subject 
to  abrupt  temperature  changes  or  exposure  to  air  or 
moisture.  Finally,  there  is  the  problem  of  maintaining 
control  of  reactors  handling  highly  exothermic  reactions. 

In  each  of  the  last  two  items  above,  close  control  of  unit 
temperatures,  purge  flows,  etc.  for  a definite  period  of 
time  is  Involved.  However,  there  is  usually  a considerably 
shorter  period  than  for  the  furnaces  mentioned  earlier. 

Where  such  special  conditions  do  not  exist,  crash  shutdowns 
can  be  handled  in  a very  snort  period  of  time. 

It  should,  however,  be  emphasized  here  that  it  is  generally 
process  plant  policy  In  continuous  process  plants  to 
continue  plant  operation  whenever  possible  unless  a 
condition  very  dangerous  to  life  or  property  exists. 

This  is  because  of  the  difficulty  ana  very  long  time 
periods  required  to  start  up  many  units  and  to  the  very 
large  losses  in  production  involved. 

Thus,  onxy  highly  exothermic  or  very  short  time  constant 
reactors  or  other  similar  units  would  normally  be  shut  down. 
Such  items  as  distillation  and  absorption  trains  which 
require  very  long  start-up  periods  would  be  kept  operating 
if  at  all  possible. 


R9H 
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U . -i  i i 7 (pr  ■'/  • us  S : : ! 1 ) — What  hit  c ui  f 1 s re  juired  ; • t 

!V,n  y 1 hand  1 “ the  emu  Host  feasible  integral  constant*: 

AN:’ WER  --  |'n  the  answer  t.  uosti  n 5 above  we  stated  that  IV- 
smallest  required  Integral  constant  was  0.  L/sec.  S inci 
an  accuracy  f f . ur  digits  was  asked  f . r n input  vnr'ab 
readings,  the  minimum  integral  correction  inv<  Lved  w uld  be: 
(0.001/sec. )(0. 0001  units)  * O.OCXXX  1 units/sec. 

Thus  seven  digits  would  be  sufficient  to  compute  the  si.  west 
integral  correction  desired. 

QUESTION  8 (Previous  QUESTION  14)  --  I-s  an  Alarm  Unil  a must  It 
simply  a desirable  one? 

What  is  your  evaluation  of  the  method  of  indicating  alarms 
by  a pre-recorded  "voice  output"  annunciator  system? 

ANSWER  14  --  An  Alarm  Unit  is  an  absolute  necessity  in  a planl 

c ntr<  1 system.  It  must  give  a distinct  Lv«  ai  d unmis ta  1 al 

indication  ; f trouble  as  s n ns  p ssibl**  after  it  •curs 

and  should  In  addition  pinpoint  the  source  and  nature  of 

this  trouble.  Pre-recorded  "voice  output"  annunciators 
offer  a distinctive  type  of  announcement  particularly  If 
in  a voice  which  Is  incongruous  with  the  surroundings 
(such  as  southern  female").  However,  such  a method  of 
Indication  would  not  have  sufficient  attraction  over 
the  present  horn  and  bell  type  systems  to  justify  the 
outlay  of  large  sums  of  money. 


-232- 


It  should  be  noted  that,  regardless  of  what  method  of 
indication  is  used,  it  should  be  repeated  until 
acknowledged  by  the  operator  to  confirm  that  he  is 
aware  of  the  presence  and  nature  of  the  plant  trouble 


QUESTION  9 (Previous  QUESTION  1.6)  --  Do  we  still  believe  that  t>  • 
sampling  speeds  Listed  in  Item  . ' . > f th<  Guide  ines  an 
adequate  for  chemical  plant  control? 

Have  wo  uncovered  any  special  cases  which  might  require  m r< 
f requent  samp  1 ing? 

ANSWER  Q --  An  extensive  study  of  plant  requirements  has  uncovered 
■ ' y a very  few  cases  where  a samplii  ■ speed  higher  tl  an  th  s< 
met tioned  in  Item  2 . 14  . f the  Guidelines  would  b«  desirabl  . 

One  of  these  is  in  the  pr  ssure  monit  ring  f hi  ;h  y ex  : u n ' : 
gas  reactors.  Here  a sampling  speed  f up  t readlt  • 

point  would  be  required.  Others  might  require  sj ds  u]  ■ c 

LO  reading  per  see  nd  per  p<  int.  However,  these  and  siml  ar 
units  ar<  s few  in  number  it  cm  ileal  plants  that  thej  c u d 
be:  included  as  multiple  points  under  the  regular  samp'!  h 
requirements  Listed  in  the  Guidelines. 
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OUEOTION  10  (Previous  jUESTT  'I  !>7)  --  What  is  th>-  present  distributi 
as  a percentage  f the  total  , of  the  various  types  of  c astro 
loops  in  our  plants? 

ANSWER  10  — Recently  a study  was  made  of  the  percentage 

distribution  of  various  types  of  actual  oontrol  loops  in 
some  of  our  largest  plants.  The  following  approximate 


numbers  were 

obtained  for  four  such  plants: 

(1) 

(2) 

(5) 

(4) 

Flow 

- 

63 

40 

30 

38# 

Pressure 

- 

10 

18 

26 

15* 

Level 

- 

10 

25 

25 

20# 

Temperature 

- 

15 

17 

18 

25* 

Analysis 

- 

2 

0 

1 

2* 

Note:  Between 

6-10#  of 

the  total 

loops  are 

arranged 

in  cascades  for  final  oontrol  actuation. 


The  distribution  of  sensors  for  process  variables  as  read 
by  the  computer  is  somewhat  different  from  this  because  of 
sensor  points  required  for  alarms,  logging,  eto.  A 
distribution  of  total  read-ln  points  required  for  input 
to  a computer  system  for  another  of  our  large  plants 
is  as  follows: 

Flow  40# 

Temperature  33# 

Level  11# 

Composition  9# 

7 * 


Pressure 


1 
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QUESTION  i;1  ( Previous  QUESTION  25)  --  Can  w<  better  define  the 
of  a control  loop? 

Possible  additional  information  which  should  bo  included  j: 
i o 1 lows • 


a)  How  many  input  variables  would  we  normally  consider  an. 
a maximum  t,  be  inv  Ived  with  any  ne  valve  actuator 
or  defined  contra  1 1 ; op. 


b)  What  is  the  rati<  . f a arms  t(  defined  ] ps? 


c)  What  is  the  rati,  of  i >gging  ut.puts  to  defined  1.  p". 

d)  What  is  the  ratio  f potential  recording  requirement,  i, 
the  number  of  defined  1 ops? 


Wh'-.  11  --  Answering  this  questi  n properly  requires  a m i'  ' 
definition  of  the  term  contr  I 1 than  has  previ  -.usly  • up 
ii  the  Guidelines  or  related  pul  icati  ns.  This  def initi 
an  follows: 


L. 


: . ncop  1. 


! 


J 
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"A  Control  loop  shall  be  defined  a r,  each  and  every  separate 
combination  of  Inputs  and  stored  quantities,  of  arithmetic  operations, 
and  of  possible  output  procedures  which  together  result  In  the 
determination  of  the  existence  of  an  error  or  deviation  from  some 
established  process  value  and  which  carry  out  the  computation  and 
activation  of  a resulting  control  or  corrective  action  which 
latter  1b  designed  so  as  to  ultimately  bring  the  process  value 
back  to  its  correct  value  or  to  compensate  In  the  process  fot 
the  detected  deviation.  In  thi3  context  each  separate  cascade 
control  computation,  each  feedforward  control  procedure,  each 
ratio  control  determination,  as  well  as  each  conventional 
control  algorithm  application  which  results  in  an  actual  valve 
or  other  final  control  element  movement  shall  be  counted  as  a 
control  loop. " 

Figure  13  illustrates  some  possible  examples  of  control  loops 

according  to  the  above  definition. 

a)  Input  variables  per  actuator  or  defined  control  loop. 

(l)  At  present  the  distribution  of  required  inputs 

(those  actually  used  in  control  computations)  per 
control  loop  averages  1.5  to  1 for  chemical  plants 
and  petroleum  refineries  and  up  to  2 to  1 for  cement 
plants  and  steel  mills.  It  is  felt  that  Die  ratio 
will  Increase  steauily  in  the  next  few  years  and 
settle  at  2 to  1 for  all  types  of  plants. 


FIGURE  13 

SOME  EXAMPLES  OF  CONTROL  LOOPS  PER 
THE  DEFINITION  OF  QUESTION  25 


(») 


SENSOR 

BASIC  CONTROL  LOOP 


SET  POINT  (2) 


SENSOR 


ELEMENTARY  CARCAl'K.  IAW 

(o) 


3F.NS0R  (l)  CONTROL  VARIAT\I*F. 

(NOT  AMONO  THE 

IN  PIT  VARIATM.KS ) 


OI  NERAI.  FORM  OF  A :;I  " 'TA1.  COirrMOL  FUNCTION 

such  as  keppeorwahi  and  AiAiTivr.  control 
(COUNTS  AS  ONI'  {■  TUMI.  1,01  r III. CASHLESS  of 
NIIMIM'I  OF  1 MINTS  ) 


FIOUHK  i ">  cont 


MULTIPLE  VALVES  - SINOLE  COMPUTATIONS  -SINOLE  INPUT 

I'MPKH  TliE  CRITERION  OP  THE  DEFINITION  OP  ANSWRH  2^1 

(d)  WOIH.D  CLASSIFY  AS  TWO  LOOPS  SINCE  TWO  SEPARATE 
CONTROL  COMPUTATIONS  ARE  MADE. 

(•)  WOULD  CLASSIFY  AS  ONE  LOOP. 
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(2)  Total  analog  inputs  per  control  loop  la  at  present 

about  4 or  5 to  1 for  most  process  plants.  It  la  our 
belief  that  it  will  decrease  somewhat  in  the  years 
to  come  and  approach  3 - 3. 5 to  1 as  extraneous  infor- 
mation is  discarded  and  more  control  loops  are  involved 
per  plant. 

b)  Alarms  per  defined  control  loops. 

Present  practice  shows  an  average  of  about  one  alarm  point 
(high  or  low)  per  control  loop.  It  la  expected  that  thlo 
number  will  Increase  to  about  1.2  to  1 as  more  sophisticated 
monitoring  systems  are  added  to  future  control  installations. 

c)  Ratio  of  logged  and/or  recorded  outputs  per  defined  loop. 

On  the  subject  of  logging  and  analog  recording,  process 
Industry  personnel  are  sharply  divided  into  several  camps 
as  follows: 

(1)  Some  wish  no  logging  whatsoever  either  permanent  or 
temporary,  being  satisfied  with  a combination  of 
permanently  and  temporarily  assigned  analog  strip 
chart  recording  for  up  to  ‘>0  percent  of  the  input 
variables. 

(2)  A second  group  would  rely  mainly  on  digital  recording 
partly  temporary  for  operator's  aid,  and  partly 
permanent  for  recording  process  data  for  historical 

J 


wge& 


1 TF.r 
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purposes  and  later  analysis.  Thoy  would  havo  only  a 
minimum  of  analog  recording,  this  to  be  temporarily 
assigned  and  used  mainly  for  analog  backup  purposes. 

A vote  among  the  attendee  companies  regarding  their  feelings 
toward  one  or  the  other  was  as  follows: 

(1)  All  companies  attending  ( 2 b) 

Would  Not  Use  Record  Prefer  Digitally  Abstain  or 

Logs  But  Rely  on  Logged  Records  No  Experience 

Analog  Recordings 

10  10  5 

(2)  Of  those  with  on-line  computer  experience  (l}) 

Would  Not  Use  Record  Prefer  Digitally 

Log3  But  Rely  on  Logged  Records 

Analog  Recordings 

b 8 

Of  those  who  voted  for  logging  the  consensus  of  opinion  was 
that  there  would  probably  be  a logged  output  for  almost  every 
input,  i.e.,  a total  of  about  3 or  4 to  1 in  relation  to 
control  loops. 


1 2 (Previous  ' 

TEST ION  ; 

1 

1 

H* 

c- 

■ : • sh  uld 

be  centr* 

si'  ed  in  , no  p- 

What  is  the  maximum  number  of  loops  which  should  be  centralized 
in  one  digital  computer  system  (this  should  be  answered  both  for 
single  computer  systems  and  for  possible  dual  oomputer  systems)? 
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What  is  the  maximum  number  of  loops  which  Bhould  be  asslgnei  to  any 
one  operator  (in  terms  of  his  performance  during  manual  control 
periods ) ? 

ANSWER  1 --  Using  control  loop3  as  defined  above  the  following  possible 

distributions  were  proposed: 

a)  Loops  per  computer  --  20  to  100,  i.e.  put  the  complete 

plant;  on  one  computer  up  to  the  1 ‘->0  loop  limit. 

b)  Loops  per  operator  --  20  to  50.  One  operator  could  handle  a 

complete  small  plant  (up  to  [0  loops).  However,  i'or  larger 

plants,  mox’e  operators  should  be  used  for  backup  control  with 
the  limit  on  required  work  being  about  50  loops  per  opera  to;  . 

c)  Loops  per  operator's  console  20  to  150.  This  is  a function 
of  numan  engineering  in  combination  with  the  rules  express.- 
above.  One  console  could  be  used  for  a 150  loop  plant  prevln.-d 
5 or  4 operators  could  work  at  it  without  interfering  with 
each  other.  Otherwise  several  smaller  consoles  should  be 
provided  with  the  loops  divided  conveniently  according  to  me 
plant  unite  Involved. 

' ■ II;  ( : 1 r ; j ■ is  . 7)  --  ■ rc  ■ " 

! •>  on  up-to-date  p ’tr  chernl  p • o > * <1  a v c 
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What  is  the  potential  for  the  use  of  multiple  cascade? 

Which  of  the  many  special  analog  computer  type  control 
algorithms  do  we  expect  to  be  included  in  the  capability 
of  the  direct  digital  control  computer? 

Gan  we  assign  any  ratio  of  such  functions  to  the  number  of 
standard  control  functions  in  the  plant? 

ANSWER  --  The  present  number  of  cascade  loops  in  a modern  chemical 
or  petroleum  plant  comprises  10-15%  of  the  total  defined  control 
loops.  It  was  the  unanimous  opinion  of  the  Workshop  attendees 
that  this  would  increase  rapidly  in  the  future  to  at  least  2‘5% 
of  the  defined  loops.  Multiple  cascades  would  be  an  important 
percentage  of  the  cascaded  loops  --  perhaps  as  much  as  one-third. 

The  attendees  were  emphatic  in  their  opinions  that  the  many 
special  analog  algorithms  would  be  a very  important  factor  in 
future  direct  digital  computer  control.  They  felt  that  most  of 
the  published  algorithms  would  be  useful  and  provision  for  their 
possible  use  should  be  included  in  the  capabilities  of  the 
computer.  It  was  the  opinion  of  the  group  that  such  algorithms 
would  also  increase  rapidly  and  would  also  approach  2S%  of  the 
defined  loops. 

The  net  result  of  the  above  would  be  that  about  half  of  the 
future  plant  control  loops  would  be  Involved  in  one  way  or 
another  with  cascade  or  other  advanced  control  functions. 
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ANSWER  --  Enough  data  must  >'  transmitted  to  assure  an  accurate 

ind  up-to-date  optimization  function  for  the  plant.  A Bug^ent-'d 
"transmission  load'  would  be  as  follows: 

1.  Transmit  a complete  set  of  plant  input  data  to  the 
optimization  computer  once  during  each  live  to  ten 
minute  period,  i.e. , ten  bit,  values.  Length 

of  thi3  period  would  be  based  on  th<  optimisation 
requirements  of  the  subsidiary  plant, 
d.  Return  a complete  group  of  new  set  points  to  the 

direct  control  computer  once  luring  each  basic  optimization 
period,  i.e.,  100.  ten  bit,  values. 

In  order  to  assure  time  coincidence  of  the  data  and  set 
points,  all  transmission  (in  both  directions^  should  occur 
within  the  same  one  minute  period  within  the  longer  block 
and  should  involve  currently  read  and  calculated  values. 

The  net  result  of  the  above  is  that  the  optimization  computer 
by  means  of  the  data  link.:  could  service  up  to  10  separate 
direct  control  computers  If  its  own  Internal  memory 
capacity  and  operating  speed  were  sufficient  to  handle 
this  computational  load.  If  fewer  subsidiary  computers  are 
Involved,  ol’f-line  scientific  or  HCeonni.Ing  work  could  be 
carried  out. 
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b)  A graphic  or  semigraphic  display  of  the  plant  should  be 
included. 

c)  Analog  display  of  process  variables  should  be  swltchabie 
and  multiplexed  approximately  t>0/l  Display  should  be  in 
the  form  of  a normalized  needle  with  the  normal  operation 
region  centered.  A color  coded  dial  instead  of  a numerical 
dial  would  be  helpful  if  feasible. 

d)  Analog  display  or  valve  position  should  also  be  switchabie 
and  multiplexed  approximately  hO/1 . It  should  present 
valve  position  as  percent  of’  full  stroke,  An  assoc  1 at  *•: 
push  button  would  be  helpful  (as  long  as  the  push  butt  on 
is  pressed  a continuous  presentation  of  the  valve  posit  ion 
would  be  given,  when  released  the  last  value  would 
preserved ) . 

e)  All  stored  constants  and  all  measured  var  iables  st-on  ic  t ■ 
accessible  to  a digital  display.  rt  would  be  d r>  s 1 ani  le 
to  have  six  separate  digital  di splays  (4  digits  earn  in 
percent  of  full  scale;. ii  not  oo  costly  per  net.  n^e 
set  would  be  used  for  each  ‘50  loops.  Tire  six  displays 
should  give  all  six  values  pertaining  to  any  one  lor 

at  the  name  time  (variable  value,  set,  point,  valve 
position,  three  sep  rate  gnlnr).  hoop  selection  should 
be  by  digit  switches. 
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f)  A SCAM  type  alarm  indication  would  be  used. 

g)  Permanently  assigned  analog  recording  would  be  wood  for 
about  15#  of  the  variables. 

h)  Temporary  (swi tenable  or  pluggable)  analog  recording 
would  be  used  for  an  additional  ‘5%  of  the  variables. 

l)  No  digital  logging  would  be  used.  All  permanent  records 
would  be  made  by  associated  supervisory  computers. 

2.  Second  Chemical  Company 

Essentially  agreed  with  the  above  views  except  for  the 

following  changes: 

b)  No  graphic  or  semigraphic  display  would  be  required. 

e)  Digital  display  should  be  to  U digits.  Displays  should 
be  in  engineering  units.  Three  separate  displays  per  net 
would  be  sufficient  instead  of  the  six  requested  above. 

g)  Permanently  assigned  analog  recording  - 5%. 

n)  Temporarily  assigned  analog  recording  - lp%. 

i)  Logging  would  be  an  integral  part  of  the  direct  control 
system. 

p.  Third  Chemical  Company 

Would  kee;  console  display  to  minimum,  use  one  net  of  four 
indicators  (percent  full  scale  needle  for  backup-digital 
1 or  normal  operation)  for  all  loops.  Have  these  indicators 
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ehow  point  number,  set  point,  variable  value,  and  valve 
position  simultaneously  under  control  of  single  rotary 
switch  system. 

The  attendees  also  gave  some  thoughts  which  they  had  on  possible 
desirable  future  developments  for  operator’s  consoles: 

a)  Plan  on  using  a data  recording  and  playback  system  such  as 

by  disk  file  and  scope  display  In  place  of  analog  strip  chart 
recording.  Recall  should  be  as  follows: 

(1)  Long  time  constant  system  information  - variables 
sampled  each  several  minutes,  allow  recall  up  to 
24  hours.  (Will  comprise  about  20%  of  loops.) 

(2)  Control  response  information  - variables  sampled  each 
several  seconds,  allow  recall  for  from  one -half  hour 
to  one  hour.  (Will  comprise  about  25-^0/>  of  loops  - 
should  be  selectable  by  dialing  Into  the  program. ) 

A third  topic  discussed  was  the  desirability  of  using  conventional 
analog  controllers  for  critical  loops  na  part  of  the  backup 
system  for  the  computer  to  relieve  the  burden  on  the  operate* 
during  the  manual  operation  period.  It  was  felt  that  C-K>T  of 
such  permanent  backup  loops  might  be  desirable  for  some 
especially  sensitive  operations.  The  effect  of  using  ouch 
controllers  upon  the  allowed  downtime  for  computer  repair  is 
shown  on  Figure  8. 


i 
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( Previ  'Us  C U ST  .. . ) - - al  ■ th  desiral  s\  :lf  ic?  1 

f<  r accuracy  . repea  tat  i tty,  and  r labt  : : .■  ’or  pr  cei  sc 

p ts  er  than  computers?  ifould  w pay  a pr  Lura  - r :urr  nl 
prices  t.  obtain,  such  characteristic 

ANSWER  --  The  Guldeli nes  calls  for  an  overall  computer  input 
resolution  and  computational  accuracy  of  0.  If  of  full  scale 
reading.  It  Is  generally  agreed  that  present  day  commonly  avail- 
able control  computers  have  about  a 1 % of  full  scale  accuracy 
for  a typical  loop  configuration  when  properly  calibrated.  i'"'ior 
normal  operational  conditions  this  rapidly  deteriorates  to 
of  full  scale,  Repeatablll  ty  and  resolution  ore  better  than  thlo- 
being  of  the  order  of  0.  of. 

The  workshop  attendees  agreed  that  eventually  a reproducibility 
and  a resolution  capability  of  0 . 1$  would  be  required  for  control 
loop  uses.  However,  an  overall  accuracy  of  If'  was  Judged  to  be 
generally  adequate.  For  yield  studies  and  overall  plant  material 
balances,  an  accuracy  of  0.1$  was  conceded  to  be  necessary. 


The  following  proposal  was  made:  "Tf  a d/p  cell  and  orifice 

Installation  fox’  flow  measurement,  costs  •!>  00  and  gives  a 

reading  with  an  accuracy  of  2%  and  a renoli  i ion  and  renrouucl hi  lily 
of  0. bfo  would  your  company  nay  $700.00  for  a flowmeter  lnstallat  Ion 
of  the  same  or  a different  typo  which  would  give  a 1$  accuracy 
and  a 0.1$  resolution  and  reproducibility?" 


SECTION  VI 


STATE-OF-THE-ART  OF  PROCEDURAL  PROGRAMMING 
LANGUAGES  FOR  INDUSTRIAL  APPLICATIONS 


Along  with  the  review  of  the  state-of-the-art  of  data 
collection,  computerized  system  check-out  and  sequencing 
control  functions  given  in  Section  III  of  this  Part , the 
attendees  at  the  First  Meeting  of  the  Purdue  Workshop  on 
Standardization  of  Tndvistrial  Computer  Languages  developed 
the  attached  report  on  the  state-of-the-art  of  procedural 
programming  languages  for  industrial  applications.  This 
report  was  published  as  pp . 25-52  of  the  Minutes  of  that 
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T < -c  1 si  ora  Tab!  nr---  1 rv.Tudod  in  on  •••••  : -in  --r,  ••  . j T,- 

Yudi  tiosa  i Comr  ! 1 1 : . : ••/•  ' } ,/1  J"  !T  A y . Ads • 

stal  ments  t<  providt  d I igging  1 s m r intr  d ■ 
in  some  or  the  language;-. 

. ■ mp ! 1 Li  met  . F.LAr  \T2  stat  ' • 

/ariation  on  tl  statement  { m its  1 • 

to  generate  relative  ^duress  references  ti  t i r:  ■'  i 

r itin  . rhis  a 1<  ws  dyt  amic  st<  ra  ■ ; I satioi 

techniques  to  1 * d withoul  modifying  1 t<  : cl  ;od 

at  execute  time. 

! Served  Words.  h ib.i-'Cl.  of  •rv-'d  wo  >■  :r  war 

d j mussed  only  in  :TL/.K>. 

. - Frog ram  Control 

Til.-*  requi rei.ient.  for  th«  pr  g rammer  to  control  th<  n.  ■ ■ 
of  . ;ran  executi  . >d  w itl  a higl  d 

i: . i formity  in  mor.t  of  f-  ■->  FORTRAT  based  1 angua.-' >r.. 

. ■ du  ing  f r<  ;rams.  rhis  was  • 1 1 i b; 

n a schedul  : ng  funot;  . { war  ' ■.pi  ••  at  ■:  : 

•!  r.ubrc-uti  no  -nl  or  by  a rt.ai  on*  add'  d t.<  : • a-  n 

1 system;  pr  id  r 1 stac 

> ''  * ■ " r • : i ■ • ' ' • for  'ut  i • • o'  ol.l  "r  : ri  ora  . . 

. ! '.in  ; n r '".nl.r  : r Tar  r . n i r war  ' i 

by  ’ ti.  1 r a subroutri  i:  call  or  by  a statement  rue  , 

ar  a . 01  I 

• • a . . v.  ••  ■ ‘ by  r il  r i ! : 

by  -1  Hi- at  ’ll 4 h ,vA  i 'i  . 




13 ocl  . A ss  to  tl  ' • •■  ■■  pr  1 d n s I 

systems . 

. . rogra:  ; rra Lnatii  - . i . • acc  mj  Is  I ' he r 

a subroutine  cal  ir  thr  • . 

or  CALL  EX  [T. 

ara 1 1 • ! 'as  Ixeeut  i n.  his  was  pr  Id  i 
Languages.  ■ - : r a r suspens i oi  ‘ a pr  r;  ... 

aecc  : p ished  by  11  r sub  rout  3 n alls  r by  at  iddi  - 

tional  statemen  . nded  'or?  th  EA1 

statement  was  alsc  urec  to  per::.!  t para ' L l tar 
as  ' ■ . READ(  I a m I ! st . 1 a l - 1 , priority.  A ' 
i a I’Ll . 

• 1 1 1 1 5 1 > Sub  rout  i eturns . is  topic  wa:  s 

X pee  la  _ -a  tur. 

. ] i rror  cov  ry.  1 i 1 W Cl  stal 

to  include  tl  r<  turt  ' error  i f rn  it j 

( lu,  forr  it, ern  r ’ 1 ' at. 

Other  i mpliMiUMitnl- 1<  a ! 1 ow  1.1. • • u ' r ■' 

status  of  th(  1 as ; ‘equesl  t r . 1 : i t< 

' I ■ i1  ‘ t i i 'fl  i •>  L ’ ; K o'. 
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• RECOMMEMDEL  : 

T ■ •'  r • ] if.  AL  LA 


From  th  proc  dings  ' Workshop  it  is 
there  are  a number  f < bas  1 tdustri; 

La  n gua  ge  s . ' . : - angua  . bas  . • ■ • 

■ ibset , the  r r a -tin  c i ar  varied . 

i-'-r  examp]  , 'n  tl  ■ f'vo  ar.  Id  tit  i ■ >d  \ 

' ' " t fur  :ti  > represented  1 y diff  r nt  f ■ 

: ' fxpressed  d >ir  of  a r ft 

at.  ■ he  Workshop  that  an  effort,  be  made  to  ext  nd  th>  • : at-  - 

bility  of  these  : angua-: 

r • ■ rocedur?  r ra  ming  . ■ ’ommitt 

" ' ■ ■ ’ : ' f >rn  • ' ' :ommit1  whos 

achieve  furl  ei tabi  Ltj  in  xisti  0]  1 \ . - . 

1 ! 1 '■  suggest  that  - 1 wing  t re<  fur  :tl  ns  b 

performed  by  the  conmi  tt*'- - . 

feasit  ' f achi  ri  mif  m ity  of 
t iona  i •'  i"--i  . : ' 1 I ‘ nv  :•  t ' yit.-’d  t and 

pr<  ' ' ' ■ a . steps  for  this  where 


mit.1  i . • ••  ■ 


:ompatabi 


A !•  I I tl 

b i 1 : t y of 


■1  extent 


x . ' i : . , 4 


w*  * • pr  'p' ■ n f vir  3 ! i wii 


• 'iv  b< 


rj  v:  ri 


r j ■ ry 
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TA]  IE  . 1 


COMPARISON 


OF  FORTRAN  EXTENSIONS 


V ' Nl'V'K 


T IMi-  K 

HOJLDS  COtn  If.l'ATh  OK  A PKtX.KAM 
EUR  A Mffjni.l)  1.1  J:iMi 


SCHEDULER 

I . IT  1 AT  i . S / *.  -i'  - OGHAM 
AT  A sniTplEU  PRIORITY 


HA  I1.1.Y 


DELAY 


m ; iv-  i i 


Cif 


ASSIGN  100  T0  IC0MP 
CALI.  TIMER  (1CU-1P,  units,  level  t 

sel«  ■„  C lull  vt  Intel  Vdl  , 
;i  Wold  temp,  block) 

CALL  D IS  PAT 


CALL  SCIU-.Dl.  (pgm  name,  p^ianutir, 
level,  word  temp, 
block) 


100  CONTI Nl’K 


I1C 


ACTION  #1  Uo  Snap  it*  every  1 sKC  EXIT  then  do  Snap 

TIMER  (START,  #1) 

STOP 


i_E  DELAY  PROGRAM,  uij , where  »uj**l  If 

this  program's  area  of  occupancy  is 
avail able  to  another  program 

11  It  area  i.*-  to  remain 
..nay  1 1 1 oh le 
m^-  length  ol  delay 


TURN  I'RtK.kAM  n 0N,  expression 
win* re  expression  - in  xt 
time  <1  Initiation,  with  aiu 
Indicating  ini.iedlrtti  ex»cutli.li 


I1UNI  YWKL1. 


DELAY  EXECUTION  II  Is  Implemented  via 
CONNECT  TIMER  and  SCHEDULE  statement 


SCHEDU1  INF  ACM  IONS 

REQUEST  PROGRAM  (parallel  idi'<  execur 
REQUEST  PROGRAM  or  REQUEST  1 K. >e.l: * 

Ihj  , . . . ,a„ ) or  HI  QUEST  PROGRAM 
(u|,  ■•••**  )10*i  »on»*equellt  . Ul 

REQUEST  PROGRAM  (h^ au)100,.: 

sorter  level 

ScViedule  label  (parallel  path  111  u pgpl) 
SCHEDULE  loo  Stale ■-..••nt  # 


irn 

CALL 

SUSl’N 

CALL  LINK 

CAl  L 

QUEUE 

CALL 

DEFEN 

GAM.  S PEC L (BACK) 

CALL 

U VI.  1. 

CALL 

DELAY 

CALI  qlkvi. 

CALL 

us  par 

CALL 

KKPEM 

CALL 

CYCLE 

GALL 

CANt  I. 

W’  S I I NGHtNiSC 

CALL  M: ST IMEK  ( ) 

LAit  M : TAS K 

S; DELAY  ( ) 

(TSI) 
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: ■:  S HOMME ND AT T 0 ■ 4 ' OF  PROHEDUKAL  LAE • '.U  ARE:'  \ vy  ' ' 


EE GAR! 7 h!  1 FURT'TER  LuE:  TERM  DEVELO!  -'HE  1 iuf  K 


5.1  The  ■ a pa  \ • : Lties  desired  for  pr<  ■ durt 
b cat  jorized  t short-te rn  . Lnte rn edial  , and  ;-l  . 

le re  are  several  funet : ..  , such  as  FORTRAN  n s t sc  i 

itines,  wh : cl  apj  ar  in  ■ us  f<  rms  in  exist!  a -tin 
iTRANS . Achieving  miformit;  for  the j fun 

" -1  rn  goal . the  5 rn  ;diate  , tt  r ar  ■ s- 

sible  FOR  IA  extens  i ns,  ; i • ■ as  bit  tnanipu  at j r and 
■ i.  valet ict  for  whicl  t Ity  tan  ! attaii  d 1 rou 

■ , nl  work  of  stand  at ' s.  Mat  y f 1 

atl  nd  s are  tonvinced  thal  1 r i : r n nts  ‘ r ; 
p >’oc  dura  ! 1 rmg- tu. ■;  ' r trial  conm’  : ■ rr  can  : 

by  J ’ ’ r.  app  r<  'n'!  - . 


. : 1 ut 

many 

.a  fiend* 

?S  feel 

that 

the  (jue 

f st; 

1 ■<:  ig,ua  ge 

s for 

ind  isl 

■ . ■ ,om] 

a it.* ' r 

shou ! d 

not  b<  rcstr j 

'•'ORTRAM 

”Xt  ‘US 

j ( ' ■ , ') 

1 though 

t 

shoul  d 

. 

■ ’ • ■ ■ • : . ' t i . ' U ' > t 

‘ • ' ' T'  1 . 

• ‘ ■ i ' T.a  ■ : - Eav  • 


.-i’ll'  ict  ' t ; th<  snort  -f  • r 
V-  r ' :•  of  L,  ■ : ' 

• - d ■ 1 . < a ■ 


b 


' • Tn  orde**  ' C >nf  n : : I : ■ ■ 

wl tf  specific  reference  i t : nt.  and  us  of 

standard  high-lev  1 language  , ■ - ■ tf  ..  ; 

and  is  directed  to  take  trie  ft  w*  . .,  . ; . 

1 . Cons<  . dal  t hi  a igua  • .■  . ■ ■ 

:i.  < set : Vi  s and  rriterij  'or  a proc 
• Examit  e t he  re  ati<  r ip  these  feal  *es 

-iTL  (and  others ) , 1 ■•■•air-  the  apparent.  :;it  i ar'  : 
1 ’ ‘ ' ■ specificati  ns  1 : ; s angu i 

5.  Develop  a plan  for: 

ir  Cpeci  ficatloa  01*  th-  language 
ii)  Trial  implementaf i or 

i'ii)  Certification  of  Mh;  v of'ffeia 


stands rd 

• ■ As  a guideline  for  .n.-ii  - 


: • . ' hi  ' win 


summarises  the  types  of  features  t.  he  :011s]  r--d,  a.-  . . . r • 

during  the  Workshop: 

General: 

Cost  and  ease  of  implementation 

natural  arigna-  • and  nyh  a • roe  ' 

ons  rcia  ' . aini  nnr 

ware  system:’,  a:  d ...  n' 
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. ' ! Job  Mnnaget:  •Hit: 

Interrupt  Response  Procedures 
Peal-time  Facilit'  :s 

i bi  Lil  y t<  ' ■ LI  Subpro  ;rams  In  Otl  >r  Lai  ;uage: 

Error  Detection  and  Recover/  Pr> •ecu ar--.;. 

Process  Task  Supervision 

Off-lin  ? Testing 

Memory  Alloc ati  on 

./  i -ita  Management: 

Data  Types  and  '•  uv-  rsion 

Logic  a 1 
Pi  xed 
: ' tatus 

1 • cision  Tab  lor. 

D a t a S t rue  1 ’e  1 Pac  k ii 

Abi  itj  : ■ icc  ss , Mai ntai  . • lii  J atf 

Jompatabi  ii  witl  ,•  nferm;  I Sys 

Mac  hi  tv-  to  Mae'"'.  1 :r  re:  ■; 

11-1  .1  ne  •:  ■''!  'i"  i P';  ' a ■ 

. J ' hi  ’ 1 ' »' • : 1 i a ■ 

• -line  C(  i’!1!'  ’I'M 

% 

I rpwa  rd  \ >mj  '!  t a t m i 1 \ -I-  t • ••  • a • 

■ •tr.i  la 

I ' rvarr  . : ' i :■■■ ; I a ' ’ " ' • ■ ■ ' " " ’ n ■ 

i'.-. ' ' :m  i ‘ . " ' 1 ''  -‘ 
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'r-np j nputati oi 

’ ; 1 * : eumental  1 Aids 

'rosy -r"--';-  • • e ; 

be  two  statements  and  variables 
tor  process  variable  interactions 
Source  Language  Diagnostics 
•5  Algorithmic  Capab : 1 it  lea : 

■ ! - - : ■ >ss  and  Sxecut  Arit  r tic 

Logical  Operations  as'ly 
Manipulation  rip  L.ymbo.i  and  Logic  Strings 
Logging  and  Reporting 
Decision  Table  Operations 
> Input/Output  Tineti.  as : 

Data  Acquisition 

■ : ' ’ : ri  rit tss i nnw  nt  of 

Process  Output  •• 'ommunic. a ai  on 
Console  and  CRT  Communication 


and 


■sou  rc 


-268- 


\EPORT  APPENDIX  T 

COMMA  RY  OP  UP  ERE  ■.'('.’MME'' 

S : CO EE  OF  T!!E  " . 


ils  r pi  ri  is  a su *y  of  1 ■■■■■.  standai 

fl  wa  r si  bmitted  I > f<  “s:  ir  . ..  ' 

hi s letter  of  ■ , . Sevenl  ' sub* 

■ tted  comment;- , f oi..et  • -n  users,  tv.  u . ' 

jomments  w<  ;r  ssentia  f of  tw 

- : r ts  isual] y "■  d ‘Icl  nele; 

s y s i 3;  and  user  function;  requirements  w i t 

staten  f how  these  ils  to  : net.  h;  dj  v 

"f  su'mmar.v  inti  tw<  • c i ass  1 <d  t- • ;ui  rem  nle  •r.d 

Y;  are  'listed  be  low  w?  * 1 : numti-r  ! ; ; ■ a r : ' ; : -r  ' 

. ...  ' "erred  ; . this  [ ' ■ . 

■ : 1 1 : summarised  b"\w  -.r  • ' ■ - ■ 1 - : < i • -d  a 7 < •>  i : v;'  ‘ .•  *••• 


r ' i duri  ; 1 
00’i1  IjAI  I CUA  'K 


'lut  Au 


The 

K ■ ’ 

1 Q r'j  ‘i  \ •}  ■■  • 

shoul  i 

1 he 

PORT  A . 

( 

The 

r 

• 

si  loul  i 

.!  be 

\TL 

The 

r<  < •• 

• ! 1 t ' ‘U 

1. 3 ' " 1 • 

.■•null 

i be 

t’l  c wel n r 

, . _ 
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■ A'l'A  r.TRIjr'TUK]V;  -'ARIAi-'LEr 

: 6 ~t  i'.yner  : 

■ ; t.  and  I ■ • ■ r ■ 

' ‘ f?®  ? 'ess  a data  quality 

■ ' " ■ ■ ■■  - r i ab  ! e. 

: • ' ' a byte  as 

I Lvalent. 

bn  ri  ab]  ec  : 

. ari  •>;  ■ 

• V V ::  ■ varlt  

i • ■ ■ («  ■■  • i£i  r 

A rravb : 


• 

’ matrix  man 

Lai  L < 

Variable 

h buffers 

Da 

‘a  Areas; 

Q 

Ability  * 
or  non- r< >s  : 

specify  data  • 
dent 

ireas  as  resideni 

1. 

Global  and 
i dent ' r ; ■ 

-■■beiod  commor 
'■!  >-  by  name 

1 perpetually 

i 1 es : 

. 

P i 1 e hand]  ; 

P.g 

. 

Pile  o ■■ 
able  with 

1 : ' 1 1 on  :’o  r y no 
T /0 

mp  . • - 

cia3  : 

■ a rat ’ i : ; • 

A systec,  f ;• 
to  a parti 
fc  Ime?  j • 

1 'ration  prccr-c 
" of ' gun 

. cin'l  1 of  -?  i *. 

A 'SO  to  tailor 
: on  (at  load 

-270- 


r ' : purj ' -out]  ut  feature: ; 

• 1 1 ( dev  ices , in  a ' i r « s , s!  i d 

■ under  pr<  ;rari  :ontrc  thr<  igl  standard 
T./O  statements. 

Par  Lie]  0 proc  sing  of  all  C device: 

standard  Lnp  t fc >■::>. • > t 

;on1  rc  1 acti  of  ; rtait  devices  shoi 
sp  f ' d;  . . , v.  ■ ■ • •'  pa.  - , etc. 

Sp  ' ■ led  ‘ormat  statemeni  ‘or  ] 
and  a 7. arming 

initia  i ation  afl  r :ompi 
COMPILER  OPERATION’ 

; . th-Hq,:  assembly  cod  • an  per  lr,l"d 

I i s >ni  ■ • j ''■■■'  ■ i r i » 

anM  r.u  L 1 i es 

At  Lut  ob  j ■ ' :oding  ■■  : 

Inn  -meni  al  add  : fc  ’ . ■ ■ w ' t r-  • t 

•C  ind  ■ i ‘ ■ 1 c ■:  n ’ • ’ ••  ■ 1 

purposes 

. r<  ‘ • fc ' ■<  :*>•.:  • •• 

. -v  1 r]  ay;',  at  c : •.  i i < : 


, r for  i -13  ■ ; ■ 

. Symbolic  coding  broutim 

PROGRAM  FOiTi  aOL 

. a d a 

; . A tardware  interrupts  :cessil 

ei  nt  ro  i 1 a ! > 1 • • by  . ! - i ;i n : i 5 * uding  sue 

’it  ••  r 

I " - t"t!  I fc 


r i 


( 1) 


r i 


( 1 
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. 

Prograni 
] anguagf  ■ 

a Loi  inherent  in  th 

4 . 

Every  pr . 

u be  ordocted  from  the 

errors  t 

her  programs 

. 

and  program  croc*  is  ton  variable 

wi  th : -'i  - 

ram 

. 

Adequate  •: 

: ' • v/1  - i the  -xecut. ; ve 

i • .'PECTAL 

. ’.tv'  ‘''ll  >r:;  ' 

as  ther  . ir  signals,  sq 

ori  f i ■ -e  y ■ t;  • , ■ .j . 

2.  Abilll  L-proces 

on vi  r< 

It* ' • ■ . : \ 


r.oAir 

toted  f roir:  t;  >- ! t '-up:--  w<‘ r 

goals  rei’lecti’  ■ d ; vttr  h -t'.-s  of  the  t.  . 

-in ! iua  '< ' ■ n ■ . ■-  ' • ■ •;  i>  i 1 1 t _y 

which  would  onnfc.i  "."'Vf  ;>yr. ! m 0t  ivrati  «->  to  be  r 

ci  ther  w;  thin  t he  . • m.  procedural  larxguag»  t ny  n; 

ft’ '.c> : no  i'  ]) rt iced  i r-  • i.  , . 

. 

Wn r,  c‘:  ! 

. > • i 1 1 r 

C , . . , ’ ,(1 

instruct' 

and  nuxi  ■ •,.*  ■ ■ I. ■ . : t code  w c fluggestr 
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UC  ' i.k-' : ' ' t > i • . " i i . , • ‘ ’l-  . 

an-:  r.tati  : 

and  T"por’  • • r t ' 

Ob  j e c : p e r al  ’ r i t 

:apab ! f b ei  • produe  i ising  1 procedure 

Lcati  rs, 

aha  !•  d ■ t „ !.■■■•  'ac ' :i- 

ructure  permit ti 

aval  ’ 'or  Lmi  < ma  :hi  ■ ■ 

C-  ' ‘I •'  1 <■'  u 

her  speci;  purpec  ■ • 

■ • y of  calling  on  1 subject  pr 

t •!■'!  U'  ••• ' . ' ■ ; d.  ■ 

. 

bl  of  an  i { ■ d bul  s uld  i 

<!■  : "i.- 


■ ■ ■ y p i ■ i 
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n'Ei'ORT  APPENDIX  II 

SU ___  IP 

rhis  rej  rt  surrn  ri  s i ’ormatior 
• • . ■ • • stionnairos  • ..  industria  i >t 

isers.  purpos  ' 5 provid 

of  ( a)  th-'*  distribution  of  industr:1  ai  systems  in  tie  viri 
dustr  ' id  ipj  . . ■ iharacl  1 ■ tic: 

’ ■ ns.  asi  for  compari  of  tl  ati 

frequ< :ncy  of  subcai  ;<  ■ ' s is  provided  as  simp  p<  rc< 

’■  ■ ' i ac  ■ • ry,  ral  tha 

. ' sys  owned) . 

' ' ' " ■ ' air  s ai  d. 
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Type  of  industry 

iuesi  ' • na  ires  fi  d by: 

Chemical  & Petroleum 
Other  (1) 


.2  Systems  s d l 

Jhemical  v tro]  m 

Oth<  r ( ' ) 


■ : i r rs  include  Metal,  Paper, 

’ - ' , v:  , ■ t'  - . , • • ' 

Type  of  proc  -c.: 

.1  i ' :iti  :r. 

. : -c  nt'ir  iu  is 

( ' - t> , '.Pi  w ) 


Typ  !’  :ontro 

. ! 1 ■■  loop 

sfi.d 

luisiti 

;-:i  tli  ti  f'!. 
ot  ’ it i ' 


'■  'tit. rol  cyr.  rh-i  ■ •'  ri  ’ 

' r ' 

■ f 

up  to  100 
10  1 -'0< 

‘>00 


mmm 


I 

i 
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4 .2  Input,/ >ut  put  distril  itlons  by  " . 


Analog 

D i g 

ital 

I nput 

Output 

Input 

Output 

None 

24 

46 

24 

24 

Less  than  2 ) 

31 

43 

33 

45 

L29-  ( 

17 

7 

10 

4 

257-512 

10 

4 

10 

513-1024 

10 

0 

17 

Over  1024 

8 

0 

13 

10 

TOTAL 

100 

100 

100 

100 

Event 

Counters 

Exl  rnal  nl  rrupt 

■tta  1 

None 

SI 

47 

Less  than  1.7 

36 

33 

17  or  over 

3 

20 

TOTAL 

100 

100 

t . 5 Distril  i ■■  : < f a 1 1 wal  ; respons 
stimulus . 

4 . 3 . ! 1 ' - ' i a ! signa  s , i n • 'u<-  i • ini  rrupt.s 


Less  than  lms 

1-10  ms  2 
10- 100ms  40 
100 -1000ms  30 
1-10  sec  27 


TOT  AT,  100' 

1.3.2  Analog  signals 

less  than  1 sec  1 

1-10  sec  6 

10-00  sec  71 

1-3  min  10 

Over  3 min 


TOTAL  100" 


1 
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System  configuration 

i Core  si  iistri 

Core  size  (1000  words) 

Less  than  8 
S-l6 
16-24 
24-'  2 

TOTAL 

Mass  m<  me  ry  av<  ability 

Not  availabli 
Drum  or  Disk 

TOTAL 

Mass  ■ nc  ry  size  distri  \ • 


25L 

21 

10 

44 


1005 


3 k 

6y 


.3.3 


Di  ski 


Size  (lOOOwords) 

L !ss  ’ hai 
L28-  ' 

-512 

TOTAL 


Size  (1000  wt 

Less  than  500 
00-  0< 
1000-1500 
over  1500 


ripher*  uij 


Type  rs 

C 

iount 

None" 
Less 
5 or 

than  5 
over 

3JS 

66 

3l 

TOTAL 

100" 

P<  I"!  ! . 


None 

One  44’ 

Over  one 

TOTAL  100*. 


rd  s i 


TOO- 


■ 


1 
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".1.  ORT-o 

C ount 

None  7C{/> 

Over  3 PS 

TOTAL  100# 

Software 


-2 


ArpLHViTioim  ..in;.- -rr:i  o; ■ ;aj  ■ 

Tii.  committee  on  Procedural  Languages  sol :!  e 1 i a ..  . ir  ■.  : 
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SECTION  VII 


SOME  ADDITIONAL  IMPORTANT  TOPICS 
PRESENTED  TO  THE  WORKSHOP  REGARDING 
THE  STATE-OF-THE-ART  OF  APPLICATIONS 


The  attached  three  reports  are  collected  together 
because  of  their  relatively  small  size.  Their  content  is 
however  very  important  in  reviewing  the  state-of-the-art 
of  the  industrial  computer  applications  field. 

The  first  report  is  a new  document  not  yet  published 
in  a Workshop  Minutes.  It  reports  a survey  recently  conducted 
in  Japan  to  determine  'ndustrial  interests  in  various  reli- 
ability techniques. 

The  second  report,  also  new,  is  a survey  of  present 
and  projected  process  computer  applications  and  research 
•ctivities  in  West  Germany. 

The  third  document  from  pp . 105-111  of  the  Minutes  of 
the  Second  Purdue  University  Meeting  of  the  ISA  Computer 
Control  Workshop  is  an  interesting  compilation  by  Mr.  R.  L 
Curtis  of  the  pertinent  time  constants  and  "dynamics'.'  of 
various  processes  and  various  management  functions. 
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REPORT  ON  JAPANESE  INDUSTRIAI.  COMPUTER  SYSTEM 
QUESTIONNAIRE  SURVEY 

GENERAL 

This  survey  was  carried  out  to  investigate  the  reliability  and 
safety  of  industrial  computer  sustains  now  operating  in  Japan,  and 
also  to  ascertain  what  levels  of  reliability  and  safety  users  will 
require  of  such  systems  in  the  future. 

The  questionnaires  were  sent  to  Japanese  users  and  manufacturer  of 
industrial  computer  systems,  and  149  questionnaires  were  returned. 

The  questions  referred  to  a wide  scope  of  problems  concerned 
with  industrial  computer  system  safety,  in  order  to  obtain  fundamental 
data  for  the  planned  activities  of  our  committee  (J EJDA's  Sub  committee 
for  Safety  and  Security  of  Industrial  Computer  Systems). 

The  questions  are  broadly  divisible  into  the  following  categories  . 

(1)  Background  Information 

(2)  System  Configuration 

(3)  Reliability 

(4)  Installation  Evironmcntai  Conditions 

(5)  Operator  Responsibilities 

(6)  Safety  Assurance 

(7)  Maintenance 

(8)  Cost/Safety  Trade-Offs 

The  most  significant  of  the  survey  findings  are  presented  in  this 
paper.  Although  ihcrc  were  many  responses  from  manufacturers, 
this  paper  stresses  tin*  information  obtained  from  user  responses. 
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RKSUIjTS  of  survey 


1.  Background  Information 

1.  1 The  number  of  repliers  and  their  type:;  of  industry 


Industrial  Classification 

Number  of 
companies 

Number  of 
systems  surveyed 

Petroleum  refining 

8 

14 

Petrochemical 

29 

.3  3 

Steel 

12 

17 

Nonferrous  metals 

8 

8 

Text  ilc 

4 

5 

ids  Cl'S 

Water  supply  and 
sewage  treatment 

5 

6 

Food 

2 

2 

Gas  and  Power 

13 

15 

j 

Rubber  , Pulp  and  paper 

6 

6 

1 

1 

1 

l’rans  portation 

7 

10 

Other 

5 

5 

Total 

99 

121 

X,  r 

Manufacturers 

” 

28 

3 .2 


When  was  your  system  installed? 


Before  1967 
'68  ~ '69 
'70  ~ '7  1 
'72  ~ '73 
'74  ~ '75 


tzu 

10(8%) 


I 1 6(5%) 


Number  of  systems 


! 32(27%) 
I 33(28%) 
I 3 3(28%) 


'76  ~ 
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1.3  What  ia  the  major  function  of  your  sy.-U'i 


Data  acquisition 
Direct  flifiilal  control 
Monitoring 

Supervisory  (setpoint)  control 
Sequence  control 
Numerical  control 
Other 


1 / I (61%) 


J '>•!(•!  5%) 
1 r>0(  1 1%) 


140(3  3%) 

ZD  /.V(24%) 


1 7(6%) 
P 8(7%) 


1.4  Did  you  evaluate  the  safety  of  your  system,  v. 
to  install  it  ? 


‘,'iic  n 


you  planned 


.--Evaluated  in  earnest  (FTA,  1- 

F.  ^ 

[—Evaluated  to 

1 some  degree 

_ .51 

16 
( 1 3%) 

93 

(77%) 

)/. 

(tO',;  1 

_ 1 

Almost  ii" 
e v . 1 1 1 1 . 1 1 i o u 


1.5  What  sorts  of  laws  and/or  standard:,  did  you  refer  to,  in 
planning,  designing,  and  installing  your  system? 


• None 


lr.  hour; c s tand  i rds 

r Law1,  and  regulations 


J 


65 

30 

— “ 

19 

(55%) 

(?6%) 

( 1 6%) 

r 1 1 1 >t  1 1 in -hour,  c 
| s landa rds , and 
law  and  regu- 
lation 

1 

[<%) 


AD-A038  058 


UNCLASSIFIED 


PURDUE  UNI V LAFAYETTE  IND  PURDUE  LAB  FOR  APPLIED  IND— ETC  F/G  9/2 
SIGNIFICANT  ACCOMPLISHMENTS  AND  DOCUMENTATION  OF  THE  INTERNATIO— ETC (U) 
JAN  77  N00014-76-C-0732 


System  C onfiguration 

What  sort  of  techniques  did  you  adopt  in  your  system  in  order 
to  increase  reliability  and  safety? 


Redundancy 
Dis  tributed 
Analog  Backup 
Manual  Backup 
Other 
None 


_ J 23(20%) 
D 20(17%) 


_□  5 2(4  5%) 


59(51%) 


D 4(3%) 

□ 10(9%) 


What  kind  of  redundant  system  will  you  require  in  the  future? 


Dual(l  1 ot  standby)  Unnecessary 

Duj)lex(Cold  standby)  ^C)tlier 


All  Indus  tries 

Petroleum  refining  j 
and  Petrochemical 

' 10  ] ,10 
(<!%):  (tr?)  1 

47 

MW  ) 

T"Tc 

(K  c j_j 

X J- 

\ 3 ( 10 

to 

J...  '< 1 

i ! \ 

\ 1 

Steel 

m a 1 

7 

( i 

f 

Gas  and  Power 

[ 4 I >* 

J « 

TT! 

Other  industries 

! * 1 '■* ...  1 . 

16 

! 7 J 

What  do  you  think  about  distributed  systems,  in  terms  of 
system  safety  ? 

-Further  evaluation  required 
r Untie  cess  a ry 

Desirable  i p - Other 

,_i j- 

8 | 4 


The  majority  of  users  ret  ard  distributed  systems  as 
contributing  to  safety,  but  they  point  out  problems  such  as  cost 
complexity  of  system  configuration,  reliability  of  the  comnmni 
cation  lines  among  stations,  etc. 
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3.  Reliability 


3.1  When  acquiring  your  present  system,  did  you  require  the 

manufacturer  to  meet  (or  furnish  proof  of  his  ability  to  meet) 
MTDF,  MTTR,  availability,  and  useful  life  goals?  Did  you 
require  a guarantee  period?  What  will  you  require  for  future 
s ys  terns  ? 

/ — Requirement  in  present  system 


MTBF 

MTTR 

Availability 


r"  143(11%) 

W777777/-Z//77\  ^(<3%) 


'W77//7/7777:a  47(48%) 


--Requirement  in 
future  systems 


] 74(76%,) 


Guarantee  period  ^2ZZZZZZ2zZ7A^y%) 

UsefuHife  3M  3 1 % ) 

3.2  What  numerical  values  did  you  specify  for  the  requi  i cou  nt  s of 
the  above  . What  were  the  actual  results? 

What  values  are  you  going  to  specify  in  the  future? 


(a)  MTBF 

(10 

Less  than  1000 
-v  2000 
~ 3000 
**  5 000 
~ 8000 
~ 10000 
~ 15000 

s.  20000 

More  than  20000 


Specified  this  Achieved  this  Will  specify 

level  for  level  with  this  level  for 

present  system  present  system  future  system 


b K3%) 


6(13%) 


□ 7(18%) 


J 10(26%) 

□ 9(23%) 


□ 7(18%) 


“ZZZZ! 1 2(38%) 
ZD  3(9%) 

ZD  4(13%) 

1 7(22%) 

ZD  4(1 3%) 

D 1(3%) 

] 1(3%) 


ZD  7(1 5% ) 

11-1(30%) 


□ 8(17%) 

ZD  10(22%) 


Ds(n%) 


□ 2(4%) 


» i X 1 
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(r)  Useful  life 


(years ) 
5 ~ 7 


Specified  this  Kxpoi  t to  achieve 

level  for  this  level  willi 

present  system  present  system 


2(  13%)  b 3(27%) 

1 10167%! 

3(20%)  Z)3(27%) 


Will  speei  i y 

this  li  tel  |’t  >r 
future  system 


"1  1 l(3fi/o) 


I6(b  j‘/o) 


12(7%) 


3.3  Which  three  computer  system  components  have  failed  most 
frequently?  Rank  these  components  in  order  of  failure 
frequency.  3’rd 


System  I/O 
Operator's  I/O 
Process  I/O:  Analog 
Process  I/O:  Digital 
CPU 

Auxiliary  storage 

Application  program 

Process  I/O:  Control 
output 

System  program 
Data  communication 
External  power  source 


1'st  2’nd  3'rd 


urir: 


Li y_Z}  32 


gCTT  ic.  . "i ic  1 30 

IZllT  29 

7)  T T~1  u I 27 

ZELL-t.  J 1^ 

ZDT0  io 

:or±]  ^ 

znas 
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Installation  Envi  r onmcnlal  Conditions 


Have  environmental  conditions  caused  any  trouble  in  your 
system?  If  they  have,  what  was  the  factor  that  caused  the 
trouble,  and  was  the  condition  within  the  specified  tolerance 
limits  ? 


5. 

5 . 1 


Temperature 

Humidity 

Power  line  voltage 
Power  line  frequency 
Power  interruption 
Power  line  transients 
Electromagnetic  interference 
Lightning  surge 
Dust 

Corrosive  gas 
Earthquake 
Vibration 
Shock 

Other  (Temperature 
g radient) 


Operator  Responsi biV> ties 


What  level  of  ability  is  the  operator  in  your  system  expected  to 
have,  over  and  above  the  ability  to  perform  the  usual  operations? 


He  is  expected  to  know  well 
not  only  the  computer  system 
but  also  the  entire  plant  and 
process . 

He  is  expected  to  have  ability 
to  operate  backup  system. 

He  is  expected  to  have  ability 
to  take  emergency  action. 

He  is  expected  to  know  well 
only  the  computer  system. 

Other 
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5.2  Which  type  of  sharing  of  responsibility  between  man  (operator) 
and  machine  (computer)  do  you  think  most  desirable  with  respect 
to  safety  during  normal  operation?  During  abnormal  operation? 


Type 

Normal 

operation 

Abnormal 

operation 

A 

Machine 

Man 

_J  39 

B 

Macliine/Man* 

Machine  /Man 

133 

c 

Machine 

M a chi  iic  / M a n 

1 24 

D 

Machine 

Machine 

□ 5 

E 

Man/Machine 

Machine 

32 

Other 

Z3  7 

* Machine/Man  means  that  machine  is  master  and  man  is 
backup . 


6.  Safety  Assurance 

6.1  What  kinds  of  automatic  functions  is  your  system  provided  with, 
to  detect  abnormalities  in  the  computer  system? 


Power  failure  detection 

Core  memory  parity  check 

Watchdog  timer 

Memory  address  check 

Analog  input  check 

Temperature  (within  cubicle) 
monitor 

I/O  address  check 
I/O  bus  parity  check 
Analog  output  check 
Other 
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6.2  What  methods  arc  used  in  your  system  to  detect  process 
abnormalities  ? 


Upper  and  lower  limit 
checks 

Rat  c-of -change  limit  checks 

Material  balance  calculation 
or  heal  balance  calculation 

Other 


25(25%) 


16(16%) 


6.3  What  methods  are  used  in  your  system  to  prevent  operator 
errors  ? 


Guard  or  inhibit  switches  for 
important  operation  switches 

Upper  and  lower  limit 
chock  on  entry  data 

Grammatical  check  of  entry 
data,  or  check  of  operation 
sequence 

Interlocking  with  other 
conditions 

Operator  guide  ( computer  - 
generated  instructions  to 
operator) 


77(68%) 


74(68%) 


69(61%) 


58(48%) 


54(47%) 


7.  Maintenance 
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7.)  Hy  whom  is  computer  maintenance  (daily , per  iudi  c , hn<T  urgent) 
now  performed? 

How  will  it  be  handled  in  the  future 


In-house  pi  rr.onnel 

Manufactur  er 

Independent 
contractor 

In-house  personnel 
and  Manufacturer 

In-house  personnel 
and  Independent 
contractor 

Manufacturer  and 
Independent  contractor 


Daily  .Now,  Periodic 

3] 


Future 


] (>H 


l*.  :::zi  m 


IT  i- ) ■ e lit 

a,., 


3?1‘1 

"Jia1 

71 

3^ 


&8 


7-10 
1Z7Z3T  3 


□7 

13  7 


□ 5 

LJ  8 


7.2  If  contract  maintenance  personnel  are  used,  how  would  you 
rate  their  services? 

^ Satisfactory  /-Unsatisfactory 

Time  to  respond  to  call 
Skill  level 


Time  required  for  spare- 
parts  delivery 

Nighttime  and  holiday 
service 

Maintenance  charge 


n7  'Y/'snyr,.  i 

. J 1 O'  ( 1 

V////.  ' u U>  i % )//// 

'./.l  -'YfaY-  > I 

l 'Ai  am ) 'A 

Y(UVJ 

I7///  //A 

(fj  %)_ 

!.'/■<’}  Oe%);  | 

in  a 0 7, ) 

It 


* 


wmmmmmmm 
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7.3  How  much  is  your  annual  system  mnintcnaiu  c cost  (in  percent 
of  initial  system  cost)? 

What  is  the  highest  maintenance  cost  that  you  would  tolc  rate? 


Hess  than  1% 
~ 2% 
~ 5 % 
~ 107„ 
More  than  1 1 % 


Now 

tZ)6(6%) 


ZJ6(6%) 

D2(2%) 


1 V>. 
'(13%) 

)3H 

(42%) 


Miximum  acceptable  cost 

(-(7%) 

zm_zzi28{v.%) 

Id 1 (49%) 


□ 7(8%) 

p3(4%) 


8.  Cost/Safety  Trade-Offs 

8.  1 About  what  was  the  initial  control  system  (instrumentation 
including  computer  systems)  cost  as  a percentage  of  total 
investment  in  plant  equipment? 


5% 
~ 10 
-v  20 
~ 50 
~ 100 


; J 26(34%) 

ZZZJ  23(3  0% ) 

Z~  1 19(25%) 

ZD  5(6%) 

ZZ4(5%) 


8 . 2 


About  what  was  the  computer  system  cost  as  a percentage  of 
control  system  cost? 


0 ~ 1 0 % 
~ 20 
~ 40 
^ 60 
~ 100 


r 
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B.3  About  what  was  (lie  backup  system  cost  as  a percentage  of 
control  system  cost? 


I 1 1(19%) 


More  Ilian  40 


1 1(19%) 

] 12(20%) 


7(12%) 


I 3(5%) 


Weighted  average:  8.6% 


8.4  About  what  is  the  annual  return  obtained  by  utilizing  your 
system  (as  a percentage  of  its  initial  cost)? 


0 ~ 1 0 % 


□ 8(19%) 

114(33%) 

6(14%) 


•v  200 
More  than  200 


Z1  3(7%) 

ZD  4(10%) 

I 6(  1 4%) 
3 1(2%) 


» f 1 11  r 

!,  - J f \ L 

\3j  “ 


r ' rfO'J 


8.5  What  benefits  have  you  realized  from  your  system? 
Rank  the  benefits  in  order  of  importance. 

tour. ) 

Personnel  reduction  o?  (fi'% )_ . __3  f'/o: % > j ] 79 

W%> 

Innroved  control  : /2 


Inproved  control  L.  — li!I' 

t tii%) r s (/  j % ) 

Increased  safety  Zj , </ (<°& .L JL fj j 3 3 

“(nj 1 

Other  (Increased  23  .i 


l’st  2’nd  3’rd  4th 


production,  etc.) 


rizzizrj 


8.6  How  much  more  (than  your  present  system  cost)  would  you  be 
willing  to  pay  for  a computer  system  that  would  be'  highly 
reliable  in  your  application? 


0% 

up  to  20% 
up  to  50% 
More  than  50% 


ZD  7(20%) 

ZD  7(20%) 

1 

□ 4(11%) 


17(49%) 
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8.7  What  sorts  of  functions  and  capabilities  would  you  require 
hereafter  to  enhance  safely  in  your  application? 

Earthquake  proof 

Temperature  and 
humidity  proof 

Intrinsic  safety 

Diagnostic  function 

8.8  What  effects  would  there  be  in  case  of  a complete  break  dov.  n 
of  your  system  (including  backup)? 

About  how  much  would  the  loss  and  damage  be  in  terms  of 
money? 


Production  loss 
Equipment  damage 
Danger  to  people 

About  15  users  indicated  amounts  of  money  for  production 
losses,  ranging  from  500,000  to  5,000,000  yen  (1,700  to  17,000 
dollars ) . 


1 67 

HU  19 
HI]  13 


A 
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COMMKNTS 

(J)  Though  reliability  and  safely  roouircmenls  should,  of  course, 

be  related  to  system  application  and  scale,  the  results  of  this 
survey  give  little  evidence  that  a significant  relationship  now 
exists,  perhaps  because  of  the  shortage  of  samples  . 

( Z ) Although  techniques  for  evaluating  reliability  are  now  com- 

paratively well  established  and  widely  employed  by  control  system 
users,  evaluating  safety  still  presents  many  difficulties  due  to 
the  lack  of  fundamental,  criteria  for  evaluation.  Check  lists  for 
evaluating  system  safety  are  therefore  urgently  needed,  and 
should  be  developed  as  soon  as  possible,  in  advance  of  establishing 
a quantitative  evaluation  standard. 

(3)  The  ques  tionnai  re  responses  indicate  that  many  malfunction 

have  resulted  from  neglecting  consideration  of  environmental 
conditions,  and  from  incomplete  specifications  of  operating 
conditions  by  both  users  and  manufacturers  . The  effect  of  some 
environmental  conditions  (in  particular , power  interruptions, 
power  line  tr ans ients,  dus t , and  corrosive  gasses)  arc  inadeq  .. 
specified  (or  not  specified  at  all)  by  manufacturers,  due  to  the 
difficulties  of  measuring  the  effects  , and  of  quantitatively 
defining  acceptable  limits  for  these  conditions. 

We  hope  that  standards  making  organizations  such  as  the  11. C 
will  actively  pursue  standardization  of  these  conditions  for 
industrial  control  systems. 

Our  regional  committee  on  safety  and  sequrity  (WCl-1),  took 
up  the  problem  of  installation  environmental  conditions  as  the 
theme  of  this  year's  activity,  and  is  now  preparing  a guideline 
concerned  with  operating  conditions  . 


Questions  about  maintenance  were  included  because  of  its 
importance  as  a factor  influencing  system  reliability  and  safety, 
and  users  responded  to  them  by  providing  not  only  the  basic  data 
requested,  but  also  extensive  comments  concerning  maintenance 
documents,  maintenance  charges,  training,  spare  parts  availa- 
bility, etc.  Wc  may  gather,  from  the  large  number  of  users 
responding  with  detailed  comments;  and  from  the  nature  of  those 
comments,  that  the  majority  of  users  have  a lot  of  problems  in 
maintaining  their  computer  systems  . 

Thus,  our  regional  committee  on  safety  and  security  (WG-Z), 
is  now  investigating  maintenance  problems  and  preparing  a 
guideline  concerned  with  computer  system  maintenance. 
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PhOCFSE  COMPUTER  APPLICATIONS  IN  THE  FEDERAL  REPUBLIC  GF  <’<•  .A ' ; 
PAST,  PRESENT  AND  FUTURE  OF  FUNDED  ACTIVITIES 


Project  Staff-PDV 
(Prepared  by  H.  Walze) 


Introduction 


In  July  1975  about  7ooo  process  computers  have  been  installed 
in  the  FRG . The  corresponding  amount  of  investment  ran  up  to 
1.8  billion  German  Marks  at  this  time.  The  recent  increasing 
of  installations  exceeds  25  per  cent  per  year. 

Since  application  efficiency  of  this  on  line  computer  power  was 
- and  still  is  - unsufficient  the  FRG  Government  decided  to  support 
appropriate  works  by  a certain  part  of  its  funding  program. 

In  1971  the  Federal  Ministry  of  Research  and  Technology  charged 
the  Nuclear  Research  Center  Karlsruhe  to  coordinate  all  funded 
process  computer  applications  in  the  FRG.  For  this  purpose  rhe 
Project  PDV  (ProzeBlenkung  mit  Datenverarbeitungsanlagen)  was 
founded  in  Karlsruhe.  It  is  managed  by  the  project  leader  Dr.  Stams 
and  a staff  of  5 scientists,  4 assisting  engineers,  2 financial 
experts  and  some  secretaries. 

The  real  work  of  PDV  startet  in  spring  1972  with  the  definition  of 
a well  established  set  of  guidelines  describing  short  and  long  term 
objectives  for  the  project.. 

In  summer  1975  funding  contracts  for  about  1 5o  works  in  industrial 
co  panics,  in  university-  and  other  institutes  were  closed. 
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The  yearly  PDV  budget  amounts  between  21  and  27  million  German 
Marks  but  the  total  amount  is  higher  because  all  commercial 
companies  pay  5o  % of  their  real  costs  themselves. 

In  the  following  an  outline  of  main  PDV  activities  is  given. 

Man-Machine-Communication 


With  the  increasing  use  of  computer  for  process  control  and 
monitoring,  human  operator  tasks  become  more  and  more  complex 
especially  when  quick  reactions  are  requested.  Therefore  the 
adaption  of  man-machine  interfaces  to  human  capabilities  is  of 
prime  importance. 

The  following  titles  of  funded  works  may  give  an  impression  of 
activities  in  this  area: 

Guidelines  and  specifications  for  computer  aided  process 
control  rooms,  development  of  certain  devices 

Data  presentation  schemes 

System  development  for  process  control  rooms 

Design  criterias  for  command  stations  in  computer  based 
plants 

Process  terminal  with  an  integrated  minicomputer 
Monitoring  equipment  for  computer  aided  line  switching 
Software 

Most  of  the  past  and  recent  efforts  are  dedicated  to  specifi- 
cation and  implementation  of  the  general  purpose  real  time  pro- 
gramming language  PEARL.  PEARL  stands  for  Process  and  Experiment 
Automation  Realtime  Language  and  was  jointly  developed  by  users 
in  industry  and  research  institutes  as  well  as  by  process  computer 
manufacturers . 
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Some  significant  accounts  of  this  high  level  language  are: 

The  subdividence  in  a system-and  a problem  part  makes  the 
usage  of  programs  for  different  hardware  configurations 
easier.  Most  hardware  dependencies  can  be  put  in  the  system 
part.  In  the  case  of  using  another  type  of  hardware,  only 
the  system  part  of  the  program  has  to  be  changed  while  the 
problem  part  remains  unchanged. 


In  order  to  achieve  portability,  a standardized  interface  to 
the  hardware  dependent  computer  operating  systems  is  being 
defined.  This  refers  mainly  to  input/output,  interrupt  hand- 
ling and  tasking. 

Besides  individual  implementations  two  portable  PEARL  programming 
systems  are  being  developed. 

One  of  the  portable  compilers  is  supposed  to  run  or.  small  target 
mini-computers  of  not  more  than  48  K core  memory. 

The  following  table  gives  a survey  of  present  implementations. 


Computertype 


AEG  60-I0 
AEG  6o-5o 
SIE  4o4/3 

SIE  3o6 
AEG  80  family 
SIE  33o 
DP  looo 
HP  3ooo 
EPP  lloo 
M'LBY  3 
.C/r,  621 
T I600 


Implementing  Institution 


University  of  Stuttgart 

University  of  Stuttgart 

ESG , Miinchen,  and  DFVLR,  Oberpfaffen- 

hofen 

University  of  Erlangen 

AEG,  Konstanz 

Siemens,  Karlsruhe 

Brown,  Boveri  & Cie.,  Mannheim 

Institut  fur  Rundf unktechnik , Miinchen 

Krupp  Atlas,  Bremen 

Krantz , Aachen 

Dietz,  MUlheim 

Software  Partner,  Darmstadt 
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In  national  as  well  as  in  international  expert  groups  PEARL  is 
considered  as  serious  candidate  for  a standardized  real  tine 
language. 

Besides  PEARL  the  problem  oriented  language  PSF  is  under  develon- 
ment  in  PDV-works  since  1973.  PSF  is  the  short  term  of  Problem- 
spezifische  Sprache  fur  Forderprozesse . It  is  tailored  for  discrete 
particle  automation  like  warehousing  or  material  distribution  in 
industrial  production  processes. 

PSF  as  a problem  oriented  language  is  of  higher  level  than 
PEARL  and  is  easy  to  learn  for  all  application  engineers  in 
this  field.  Furthermore  PSF  is  an  appropriate  tool  for  olannlng 
purposes.  It  is  easy  to  implement  on  computers  which  already 
have  PEARL  compilers. 

In  the  present  PDV  project  plan  the  submission  of  PSF  is  envisage 
for  1977. 

The  long  term  goal  for  all  works  in  that  field  provides  a rcrmou 
software  production  system.  With  such  an  integrated  svstem  the 
overall  cost  for  software  generation  can  be  reduced  rapidlv. 

It  will  consist  of: 

Precompiler  for  supporting  structured  programming  and 
decision  table  applications 

Means  for  source  proqram  handling  like  editing  and 
macrogeneration 

Means  for  compilation  and  interpretation  of  source 
programs 

- Mounting,  linkinc  and  loading  programs  for  object  codes 
Machinecode  generators 
Test  means 


etc . 
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Hardware 

The  fast  progress  in  the  field  of  mini  CPU's  and  microprocessors 
does  not  solve  interface-  and  other  problems  occuring  when  computer 
power  has  to  be  integrated  in  a process  control  system. 

Here  the  following  goals  can  be  derived  from  the  users  require- 
ments : 


Special  application  dependent  design  cost  must 
be  reduced 

Commissioning  and  installation  cost  must  be  reduced 
The  system  must  be  more  available  and  more  reliable 
Operation  and  maintenance  features  must  be  improved. 

The  global  approach  for  a solution  is:  Intelligence  distribution. 
Therefore  many  PDV-works  contribute  to  design,  development  and 
implementation  of  modular  decentralized  systems  with  standard 
interfaces . 

The  common  base  of  these  developments  is  a bit  serial  line  sharing 
system  - the  PDV-Bus  - with  uniform  interfaces  to  all  attached 
stations.  It  makes  start  up  and  maintenance  much  easier  and  enables 
compatibility  between  system  components  from  different  sources. 

The  PDV-Bus  concept  is  being  developed  since  spring  1974.  it  is 
now  in  the  phase  of  implementation.  The  mandatory  part  of  the  bus 
specification  comprises  communication  protocols  and  hardware  inter- 
face functions. 

Characterizing  features  are: 

Hierarchic  structure  based  on  the  master-slave  scheme 
Slavestations  with  and  without  demand  capabilities 
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- Communication  path  without  active  components  enables 
passive  bus  couplers  (T-Junction) . 

Procedures  with  command  - reply  sequence  (commands  from 
master  to  slave  (s)  and  replies  from  slave  to  master) 

Transmission  of  single  16  bit  data  or  data  fields  with 
variable  length  (n  x 16  bit) 

252  slavestations  in  maximum 

8 bit  CRC  field  always  checks  16  preceding  information 
bits 

Asynchronous  demand  requests 

High  efficient  status  polling  procedure 

- Direct  communication  between  2 slavestations  as  option 

Between  busline  and  slavestation  all  informations  are 
transferred  as  NRZ  signals  accompanied  by  separate  clock 
pulses 

Eight  basic  types  of  transmission  procedures  are  defined: 

Global  commands 
Individual  commands 

Writing  of  single  data  (master  — »-  slave) 

Writing  of  data  fields 

Reading  of  single  data  (slave  — master) 

Reading  of  data  fields 

Reading  and  writing  of  single  data 

Reading  and  writing  of  data  fields 

First  experiences  with  the  PDV-Bus  are  expected  for  1977. 

The  system  proposal  was  also  submitted  as  working  paper  to  the 
Technical  Committee  on  Interfaces  and  Data  Transmission  (TC  5) 
which  is  part  of  the  European  Purdue  Workshop  on  Industrial  Computer 
Cys terns . 


-307- 


For  the  PDV-Bus  appropriate  control-  and  monitoring  equipments 
as  well  as  DDC-  and  CNC  slavestations  are  being  developed.  Many 
of  them  are  based  on  microprocessores . 

As  an  alternative  for  the  present  analogue  and  the  future  digital 
field  instrumentation  components  using  frequency-analogue  signal 
notation  were  developed. 


Their  advantages  are 

Signal  structure  permits  simple  and  inexpensive  conversion 
in  digital  values  (using  simple  counters!) 

- High  noise  immunity  (comparable  with  digital  notation)  can 
be  achieved 

High  accuracy  allows  applications  in  dosing  processes  like 
weighing  etc. 


Certain  prototypes  are  partly  under  test  in  industrial  plants  and 
the  wide  commercial  introduction  is  intended.  Nevertheless  the 
step  to  common  industrial  use  is  not  yet  done. 

For  ACO  (Adaptive  Control  Optimization)  machine  tool  control 
systems  special  sensors  with  high  accuracy  and  sensitivity  were 
developed.  In  detail  sensors  for  tool  wear,  for  the  approach  of 
tool  to  the  material,  for  cutting  force  and  for  material  surface 
roughness  are  available.  Application  areas  are  cutting  processes 
like  turning,  drilling,  milling  and  grinding.  These  works  were 
performed  in  several  university  institutes  being  coordinated  in 
the  so-called  HGF  (Hochschul^ruppe  Fertigungstechnik ) . 

Another  important  PDV  subject  are  two  methods  for  automatic 
diagnosting  of  hardware  faults  in  computers.  One  method  makes 
use  of  the  "none  exact  dictionary  matching",  the  other  evaluates 
logical  bit  sequences  appearing  at  a certain  time  at  different 
test  points. 
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Compared  with  conventional  diagnosting  techniques  these  advanced 
statistical  methods  operate  with  a smaller  data  base  and  are 
widely  computertype  independent.  They  are  implemented  for  an 
AEG  60-I0  computer  as  test  object.  The  diagnosis  is  controlled 
and  evaluated  by  an  external  test  processor  realized  with  an 
AEG  6o-o7  (Interdata-CPU) . 


Pilotsystems 

The  third  class  of  PDV-works  are  exemplary  control  computer  apnli 
cations  in  certain  industrial  branches. 

The  most  important  representative  is  the  FFS  (Flexiblcs  Fort:  our.  - 
system),  an  integrated  system  for  computer  managed  rar*  - -an  ■ ac* 
ring.  The  FFS  will  be  realized  in  a cooperative  mans,  r ! «’  ■ 

university  institute  and  a big  manufacturer  for  Die-  . ] « • r . 
parts  of  them  (MTU) . 

The  system  is  expected  to  automate  metal  cuttine-  1 r. 
processes  in  a MTU  factory. 

Nearly  ten  different  types  of  engine  parts  like  -vIp.  !■ 
will  be  produced  on  six  numerical  controlled  vw 
with  automatic  tool  changing  and  load/unload  d<  .1 
tool  centers  are  linked  together  and  with  a store  sy  • 
all  parts  and  tools  can  be  transported  by  computer  c 1.'  ■ 

It  is  intended  to  integrate  the  FFS  into  the  current  Mil  ->r re.-* 
in  1979. 

A second  pilotsystem  which  should  be  mentioned  was  designed  by 
BFI  (Betriebs-Forschunos-institut)  for  computer-control  led  steel- 
melting in  an  electric  arc  furnace. 


Here  the  energy  distribution  control  system  monitors  the  electrical 
power  consumption  and  allots  the  disponable  melting  power  to  the 
different  furnaces.  This  happens  in  accordance  with  their  priorities 
at  a certain  time. 

The  comupter  based  furnace  control  additionally  records  the  charging 
run  off  and  optimizes  the  electrical  arc  operating  parameters. 


The  attached  PDV  publication  list  reflects  past  and  present  topics 
of  funded  activities  (it  is  only  a selction) . 


All  KFK-PDV  reports  are  available  from 

Projekt  ProzeBlenkung  mit  DV-Anlagen  (PDV) 
Gesellschaft  fur  Kernforschung  mbH 
Postfach  364o 

75oo  Karlsruhe 
Germany 


KFK-PPV  1 

K.H.  Timmesfeld,  B.  Schiirlein,  P.  Rieder,  K.  Pfeiffer,  G.  Muller, 

K.  Kreuter,  P.  Holleczek,  V.  Haase,  L.  Frevert,  P.  Elrer,  S.  Eichen- 
topf,  B.  Eichenauer,  J.  Brandes: 

PEARL  - A proposal  for  a process-  and  experiment  automation  realtime 
language 

KFK-PPV  3 
R.  Werthmann: 


Decision  table  preprocessor  for  control  systems  (system  design) 
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KFK-PDV  5 

H.  Herbstreith,  P.  Kossmann: 

Performance  characteristics  of  today's  process  control  computers 


KFK-PDV  6 

R.  Werthmann,  E.  Kazis: 
Interactive  dialog  system 


KFK-PDV  lo 

P.  Namneck,  I.  Schnarre,  K.  Wagner: 

MULI  - Multi  Level  Dialog  System, 

Multi  Level  Dialog  Language  - description  of  language  and  system 


KFK-PDV  11 

P.  Namneck,  I.  Schnarre,  K.  Wagner: 

MULI  - Multi  Level  Dialog  System, 

Multi  Level  Dialog  Language  - case  studies  for  application 


KFK-PDV  12 
E.  Kazis: 

Interactive  Dialog  System  Part  II 


KFK-PDV  13 

W.  Kntzsche,  U.  Voges: 

GAUSS  - a System  for  Structured  Programming 
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KFK-PDV  14 

H.  Unbehauen,  B.  Bauer,  B.  Gdhring,  Chr.  Schmid: 
"On  1 ine"- Identification  Methods 

Evaluation  of  Literature  and  Review  of  the  Methods 


KFK-PDV  17 
Rudi  F.W.  Grimm: 

Comparison  of  Redundancy  Reduction  Algorithms  with  respect  tc  System 
Protection  Using  Process  Controllers 


RFK-PPV  21 

Hans  D.  Hoelzer , H.  Rock,  J.  Waidelich: 

Methods  of  detecting  and  locating  faults  of  combinatorial  and 
sequential  circuits 

KFK-PDV  26 

H.  Unbehauen,  F.  Bottiger: 

Control  algorithms  for  implementation  on  process  control  computers 


KFK-PDV  28 
E.  Verhaag: 

Machine  tool  control,  computer  linked  numerical  control 


KFK-PDV  3o 

F.  Freyberger,  G.  Landvogt,  G.  Schroder,  H.R.  Trankler: 

Use  of  Frequency-Analogue  Signalnotation  for  Computer  Aided  Process  Control 


- — ■ 


I 
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KFK-PDV  33 
G.  Farber: 

Redundant  Serial  Loop-Syster.  wit:  standardised  Interfaces 


KFK-PDV  37 

H.  Unbehauen,  Chr.  Schmid,  F.  Bottiger,  B.  Bauer,  B.  Gohring: 

KFDDC:  A combined  process  computer  program  system  for  the  design  a..^. 
application  of  DDC  algorithms 

KFK-FDV  38 
R.  zimmermann: 

Design  of  man-machine-communication-systems 

Basic  human  factors,  demands  and  recommendations 
KFK-PDV  41 

K.  Essel,  W.  Hansel: 

Development  of  sensors  for  process  control  systems  in  the  field 
of  production  engineering 

KFK-PDV  42 

R.  Hoefert,  J.  Lemmrich: 

Compilation,  classification  and  evaluation  of  components  for  fre- 
quency analogue  process  instrumentation  systems 

KFK-PDV  44 

H.J.  Gdnther,  W.  Werum,  H.  Windauer: 

Problem  oriented  language  for  transport  systems,  language  report 


j 
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KFK-DDV  -'.7 

W.  Patzelt,  M.  Salaba: 

A method  for  performance  comparison  of  DDC  algorithms  ard  application 
of  this  method  to  selected  cases  by  means  cf  the  computer  program  OPTAD 


KFK-PDV  5o 

H.  Birk,  G.  Farber,  K.  Hailing,  D.  Heger , M.  Patz,  E.  Holler,  H.  Walze: 
"Mikroprozessoren  und  Mehrprozessorsysteme  fur  die  ProzeBlenkung" 


KFK-PDV  53 
F.  Wagner,  H.  Woda: 

"Process  Basic" 

KFK-PDV  54 

R.  Isermann,  D.  Bux,  P.  Blessing,  P.  Kneppo: 

Control  Algorithms  for  direct  digital  control  with  process-computers 
KFK-PDV  56 

SCS,  Scientific  Control  Systems  GmbH: 

MUL1  - Mulit  level  dialog  language  - language  and  system  description 

KFK-PDV  59 
H.  Siefkes: 

A microprogrammed  process  unit 

KFK-PDV  ho 
K.  Giith: 

Kicroprogrammable  Interface 


1 

1 

i 


A. 
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lanuary  3 3,  1973  — \ 


Dr.  T.  J.  Williams 
Purdue  Laboratory  for  Applied 
Industrial  Control 
Purdue  University 
Lafayette,  Indiana  47907 

Dea r Ted , 

Enclosed  are  the  diagrams  I promised  you,  in  connection  with  the  ISA 
workshops. 

Figure  I shows  some  representative  process  time  constants.  These  figures, 
even  for  a given  type  of  control  loop,  such  as  a pressure  control,  vary  over 
quite  a wide  range,  due  to  system  capacities,  flow  rates,  and  available  energy. 
Thus,  the  pressure  in  a large  reactor  may  exhibit  a response  time  of  the 
order  of  several  seconds,  while  a hydraulic  servo  positioner  such  as  an 
antenna  control  system  may  operate  in  the  millisecond  range.  Because  of 
considerations  like  this,  I shudder  whenever  someone  generalizes  to  the  ex- 
tent of  saying  that,  in  a ddc  system,  pressures  should  be  sampled  about 
once  per  second  ".  Indeed,  in  the  antenna  positioning  example,  the  pressure 
control  loop  may  be  entirely  inside  a speed  control  loop,  which  is  in  turn 
inside  the  position  loop  of  interest.  In  this  case,  maybe  the  position  can  be 
sampled  about  once  per  second  for  adequate  control,  but:  the  speed  and  pres- 
sure loops  would  operate  at  increasingly  faster  sample  rates. 

Cascaded  controllers  with  adaptive  features  further  complicate  things,  be- 
cause inner  loops  may  be  directed  by  the  dynamic  behavior  of  outer  loops, 
and  sample  times  can  be  adjusted  as  part  of  the  control  strategy,  tin  top  of 
more  conventional  practices  of  adjusting  set  points  or  providing  compensa- 
tion for  measurements. 

If  workshops  are  to  produce  guidelines  for  system  design  activities,  some 
of  these  guidelines  may  well  have  to  be  dimensionless  in  order  to  be  useful. 

An  example  is  the  ”4  samples  per  time -constant  rule,  which  can  be  restated 
as  the  ratio  of  sample  time  to  response  time  (1/16  in  this  case). 

Some  relative  ranking  of  the  dynamics  of  nested  control  loops  is  also  useful, 
such  as,  in  the  case  of  strictly  linear  loops,  that  each  succeeding  inner  loop 
(of  <i  stable  system)  will  generally  respond  about  twice  as  fast  as  the  loop 
around  it.  This  can  be  carried  further,  for  non-linear  systems,  by  saying 
that  the  extent  to  which  this  rule  of  3 is  violated  is  a measure  of  either 
non-linearity,  instability,  or  sluggishness. 
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Figure  2 continues  the  idea  of  structuring  generalizations  into  a useful  form, 
on  aTTyna  mic  scale.  The  lower  four  (4)  curves  represe  nt  typical  ranges  of 
regulators  and  sequencing  control  systems  as  used  in  industrial  manufac- 
turing operations.  There  a n exi  options  to  these  ranges,  of  course,  but  it 
is  my  experience  that  the  majority  of  control  applications  fall  into  these 
ranges.  Further,  the  relative  differences  between  the  control  technologies 
shown  app<ar  to  be  real. 

The  big  jump  shown  for  autoi  \itii  ulti variable  c ontrol  is  due  partly  to  the 
tact  that  such  systems  j ipim,  inw  ne  quite  complex  and  tend  to  be  digital, 
with  memory  that  is  adequate  for  <ht  handling  and  correlation  of  extr.  mel\ 
slow  variables.  (A  human  operator,  attempting  to  operate  over  this  wide  a 
dynamic  range,  has  difficulty  remembering  enough  information  to  form  Un- 
necessary correlations,  and  he  ilso  has  trouble  observing  rapidly  changing 
ariables  and  responding  to  them. 

T lie  solid  bars  from  the  fifth  level  upv.  a . d represent  th<  typical  dynamic 
ranges  of  production  monitoring,  production  control,  and  general  busine  s 
informaiion  systems,  and  are  designed  to  aid  people-  at  various  levels  in 
business  management  hierarchy.  The  dynamic  ranges  of  the  people  them- 
selves, at  various  levels  of  the  hierarc  hy,  i re  represented  by  the  dasher 
horizontal  bars  near  their  corresponding  information  system  graphs.  Since 
the  information  system  used  by  a person  at  a given  level  is  part  of  lus  pro- 
cess sensor  system,  it  must  be  capable  ot  faster  dynamic  performance  than 
the  person  who  is  acting  as  the  c c nt  roller. 

In  i structure  such  as  this,  it  must  he  remembered  that  some  activities  are 
n t represented  by  the  structure  , and  that  the  information  and  control  system 
,n  the  people  sometimes  operate  outside  the  dynamic  ranges  shown.  1 bus , 
i!  the  plant  manager  wants  a pencil  sharpened,  he  can  certainly  sharpen  it 
himself  in  less  than  half  a day,  but  if  he  delegates  the  job  down  to  a produe.  - 
tion  or  maintenance  worker,  it  may  very  well  take  that  long.  1 he-  chart  of 
t'igui  e 2 is  intended  to  show  the  relative  dynamic  s ot  tasks  that  operate  by 
clegation  down  thru  the  organization,  re  lated  to  the  hierarchy  of  pe  >pl«-  no 
information  systems  that  make-  up  tl  is  , i gani-ation. 

't  has  been  known  for  some  time  by  . ontrol  system  engineers,  that  they  ust 
e - i thorough  job  of  human  engineering  in  order  to  achieve-  a satisfactory 

>f  . quality  known  as  "ope  rator  a • • eptanc  <- , to  make  a s y s t on  per'-  :oi 
i<  -'unctions  as  intended,  inc!  ti  achieve  the  greatest  benefit  for  the  engineer! 
v i* ! that  a system  represents.  1 h ive  observed  tl  at  people  <d  all  levels  in 
hie  ' a rchv  tend  to  tailor  tln-ir  jobs  until  they  achieve  some  level  of  personal 
satisfaction,  or  ' comfort.'  i agonal  shaded  stripe  of  figure  2 represe  nt 

the  approximate  locus  of  such  otiif  rtablc  Ope  ra  ting  Points  K OIM  lor  ' ■ ! 
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[f  a man  is  too  busy  (or  uncomfortable)  at  a task  that  is  quite  dynamic,  he 
will  tend  to  ignore  some  requirements  until  he  achieves  a comfortable 
operation,  that  he.  can  handle  to  his  own  satisfaction.  This  sort  of  opera- 
tion may  not  result  in  ranking  of  priorities  in  the  same  way  these  priorities 
might  be  ranked  by  the  man's  supervisor,  though,  so  the  result  may  be 
organizational  conflict. 

On  the  other  hand,  if  a given  job  is  too  routine,  with  nothing  happening, 
a man  tends  to  make  work,  of  his  own  choosing.  Some  of  this  made-work 
can  be  of  benefit,  but  the  yield  in  this  respect,  as  far  as  the  overall  organi- 
zation is  concerned,  is  apt  to  be  low  if  such  activities  are  without  purposeful 
direction. 

It  appears  to  be  a valid  system  engineering  strategy  to  recognize  the  signifi- 
cance of  the  COP's  of  the  people  who  are  to  build,  operate  and  maintain  sys- 
tems, regardless  of  their  relative  hierarchical  level,  and  to  design  these 
systems  in  such  a way  that  the  human  organizations  mesh  construc  tively  with 
the  resulting  organization  of  mechanisms  and  information  systems.  Industrial 
psychology,  with  its  emphasis  on  job  enrichment,  is  part  of  this.  So  is  a 
thorough  knowledge,  on  the  part  of  the  systems  engineer,  of  the  various  or- 
ganizational objectives  and  the  personal  objectives  of  the  people  involved, 
plus  their  relationship  to  his  own  objectives. 

The  integration  of  man/machine  organizations  also  involves  the  observation 
of  biological  constraints,  as  depicted  by  the  vertical  line  marked  °<  0.  007  sec, 

which  marks  the  area  of  human  mental  operations.  Sequential  mental  processes 
seem  to  be  limited  here,  so  a person's  ability  to  observe  a process,  correlate 
the  observation  with  a pattern  of  desired  process  behavior,  and  take1  action  has 
a definite  break  frequency.  The  system  engineer,  through  knowledge  of  these 
kinds  of  limitations,  may  be  able  to  design  operator  interfaces  in  such  a way 
as  to  take  advantage  of  the  human  capacity  for  parallel  processing  (pattern 
recognition),  to  perform  more  elaborate  correlations,  and  to  eliminate  the 
need  for  a large  number  of  sequential  thought  processes. 

At  the  other  end  of  the  spectrum,  a person's  memory  is  finite,  and  organi- 
zational jurisdictional  boundaries  form  constraints  to  human  band  width  at 
various  levels  of  the  hierarchy. 

Note  that  this  representation  does  not  account  for  such  phenomena  as  local 
motor  control  (in  the  human  body),  where  the  thought  processes  operate  in 
a supervisory  mode,  and  the  limbs  perform  high-speed,  usually  repetitive 
and  complex  functions  by  reflex  action".  These  functions  involve  training 
in  manual  dexterity  and  coordination,  and  are  perhaps  physically  demanding 
but  do  not  involve  mental  fatigue.  Such  functions  may  legitimately  be  designed 
into  , job,  as  in  the  case  of  bilateral  servos  employing  force-feedback,  to 
take  advantage  of  the  human  ability  to  sense  and  control  tactile  phenomena 
by  motor  control  without  conscious  thought.  An  experienced  motor  vehicle 
onerator,  driving  along  a freeway,  operates  mostly  in  this  mode. 


The  vertical  scale  of  figure  2 is  not  labeled,  but  I suspect  it  has  something 
to  do  with  the  impact  of  decisions  made  at  various  levels  of  the  hierarchy, 
with  the  impact  increasing  as  the  top  of  the  hierarchy  is  approached.  Im- 
pact, in  this  sense,  is  a measure  of  the  futurity  of  decisions,  and  a high- 
impact  decision  cannot  easily  be  reversed  or  corrected.  Some  of  the  differ- 
ences in  impact  are  thus  due  to  the  inertia  of  the  hierarchy  itself,  but  ideally 
most  differences  would  be  due  to  deliberate  design  of  a management  structure: 
the  division  of  management  responsibilities  to  correspond  with  experience 
a vailable. 

Besides  the  dynamics  and  impact  attributes  of  jobs,  there  are  many  other 
factors  that  go  into  the  design  of  hierarchies,  such  as  freedom  of  action, 
know-how,  the  nature  of  interpersonal  relationship,  the  geographical  distri- 
bution of  functions,  materials  and  information,  training  costs,  etc.  A systems 
engineer  certainly  has  a lot  to  consider,  if  he  is  to  successfully  design  elab- 
orate hierarchies  of  man/machine  systems.  I suggest  that  the  simplest 
strategy  for  making  the  dynamic /impact  tradeoffs  would  be  to  attempt  to 
structure  the  jobs  of  a hierarchy  so  that  the  locus  of  all  jobs  lies  roughly 
along  the  COP  locus  (rather  than  horizontally,  as  shown),  so  that  each  job 
has  a mix  of  both  impact  and  dynamic  content,  and  so  jobs  effectively  form 
a continuous  spectrum  through  the  chain  of  command,  with  each  job  covering 
a dynamic  range  of  about  two  (2)  decades. 

On  the  mechanical  side,  the  geographical  distribution  and  task  breakdown  of 
an  hierarchical  system  of  control  equipment  does  not  lend  to  simplistic  solu- 
tions either.  Much  of  the  literature  on  hierarchical  system  philosophies  has 
attempted  to  arrive  at  neat  divisions  of  tasks  that  lend,  in  turn,  to  neat  block 
diagrams.  Much  consideration  must  be  given  to  other,  more  important  factors, 
such  as:  1)  matching  built-in  isolating  effects,  such  as  queueing  areas  or 

storage  capacities  of  a process;  2)  providing  for  fault  isolation;  3)  allocation 
of  controller  loading;  4)  distribution  of  information  sources  and  sinks;  51  a v,  li- 
ability of  communications  resources;  6)  economics  of  scale;  7)  economics  of 
specialization:  and  of  course,  H)  the  nature  of  the  human  organization. 

Arbitrarily  limiting  a local  ddc  controller  to  only  the  last  loop,  or  last  few 
loops  of  a cascaded  system  is  apt  to  lend  to  poor  economics  in  the  use  of 
digital  control.  Manufacturing  control  extends  from  the  marketplace  to  the 
Boardroom,  and  on  down  to  the  process,  and  can  contain  dozens  of  levels. 
Division  of  these  levels  into  suitable  hardware  hierarchies  is  a first  - < la 
systems  design  problem,  and  should  not  be  glossed -ovc  r with  simple  obi! 
osophies  that  make  neat  block  diagrams. 


R.  L.  Curtis 
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